Home › Forums › TinyG › TinyG Support › Limit switches not working, config changes not being saved
Tagged: Parms in 'inches'
- This topic has 12 replies, 3 voices, and was last updated 11 years, 7 months ago by cmagagna.
-
AuthorPosts
-
March 17, 2013 at 11:32 pm #3880cmagagnaMember
I recently got a TinyG for a supersized ShapeOko I’m building. So far so good, but I’m having three problems.
1. I can’t configure limit switches. Homing only works, but options 2 and 3 don’t:
$xsn=3
[xsn] switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
tinyg [inch] err: Input value unsupported: $xsn=3
$xsx=2
[xsx] switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
tinyg [inch] err: Input value unsupported: $xsx=2
I saw in the thread “Can’t set switch to limit mode” but that says the bug was fixed in 370.04, and my firmware build says 370.05.
2. Some of my config changes get lost on reboot. When I make changes like these:
$xvm=500
$xfr=250
$xjm=5000000
$xjh=5000000
$xsv=15
$xtm=6.5
after a reboot they’re back to the default values:
[xvm] x velocity maximum 19.685 in/min
[xfr] x feedrate maximum 9.843 in/min
[xtm] x travel maximum 0.256 in
[xjm] x jerk maximum 196850 in/min^3
[xjh] x jerk homing 196850 in/min^3
[xsv] x search velocity 0.591 in/min
3. I’ve got the coolant on/off pin connected to a relay (via an optoisolator). When I issue M8 (coolant on – flood) the relay sounds like it’s being driven by PWM, it turns on and off 15-20 times per second (the actual pulse rate may be higher, but I’m using a mechanical relay so I can’t confirm). I’d have thought M7 (coolant on – mist) would use PWM, but for M8 the port would turn on and stay on solid. Is this a bug or by design? (In case you’re wondering, I’d hoped to use M8 / M9 to control the relay for vacuum).
Thanks in advance for any help.
March 18, 2013 at 6:54 am #3882aldenMemberLet’s hit the issues one by one.
– First, confirming you are on build 370.05
1. You have discovered a bug in the switch settings. I will need to fix that an make a new push. We have just started shipping TinyG with a boot loader. Does you board flash the Spindle PWM LED when you hit reset? If not, you can reflash the board using an AVRISP mkii programmer, or we can do a swap with you. Sorry for the inconvenience.
2. Looks like the settings are correct, but they are reporting in Inches units. If you type g21 do they come back correctly? If you want the board to power up in mm mode type $gun=1
https://github.com/synthetos/TinyG/wiki/TinyG-Configuration#gun—gcode-default-units
3. The coolant controls seem to be working normally on my board – I’m not sure what you are experiencing. The Mist and Flood share the same pin, which is the coolant on/off pin. The Spindle PWM should not be affected. Can you confirm that you get the following behaviors –
– M7 turns on coolant light
– M9 turns off coolant
– M8 turns on coolant
– M9 turns it off again
The Spindle PWM does not light in any of these cases.
Check that your opto can handle a 3v logic signal. The board is 3.3v and the outputs are about 3v.
Hope this helps
Alden
March 18, 2013 at 6:23 pm #3885aldenMemberOK. This should be fixed in build 370.06 from the master branch.
March 18, 2013 at 11:34 pm #3886cmagagnaMemberThanks for the reply.
Regarding #1, I saw your fix at github. I don’t have any way to reprogram the board so I will need to do a swap. Thanks for your help.
#2 – The system is definitely set to inches ($gun=0, and that sticks on reboot) but I think everything is being saved in mm, or there’s a conversion bug somewhere. When I set $xvm to 500 (in G20 mode, e.g. X velocity maximum = 500 inches / minute) it works, but on reboot it goes back to 19.685 in/min. This works out to 500 mm / min, so I think the “500” is being saved but not the “in inches” part.
Similarly, when I set motor travel, e.g. $1tr=1.358, it works but on reboot it goes back to 0.053 in, which works out to 1.358 mm.
So I think you’re correct in that the numbers are being saved to EEPROM, but not the units.
I can/should/will probably rework all my code to work in SI instead of Imperial, but I do think this is a bug you should look into at some point.
#3 I looked through the source today at work and you’re right, there’s no PWM being done on the coolant pin. Sorry for assuming this. I just finished tracing out the relay wiring and it looks like this is a hardware problem with the relay and not with the code. I apologize for my error.
Chris
March 19, 2013 at 3:00 pm #3887aldenMemberChris,
You need to set your variables in the right units mode. To set the units mode enter the following Gcode:
G20 set machine to inches mode
G21 set machine to mm mode
The settings you then enter will be in the units you have just set. Be aware that a G20 or G21 in a Gcode file will set the units mode as well.
You can tell what mode the machine is in by looking at the text mode prompt.
You can also set the mode the machine starts in after reset
$gun=0 sets inches mode on reset
$gun=1 sets mm mode on reset
Please try this and see if you are still having problems. If so, it might be a bug – but at the current time I’m not sure that it is.
Alden
March 20, 2013 at 12:41 pm #3893n7qvuMemberI have the same issue.
TinyG info:
[fb] firmware build 370.05
[fv] firmware version 0.95
[hv] hardware version 7.00
[id] TinyG ID 9H3906-SWXI tried many different ways and cannot get variables to save correctly while in “inches” mode. I tried $gun, G20 etc and never could save parms($1tr, 2tr) in “inches”
I gave up, converted to mm and saved the parms…with no issues??
Jerry
March 20, 2013 at 1:53 pm #3895cmagagnaMemberHi Alden,
I’ve verified this bug. The values are being saved, but not the units. Here’s an example where I reboot the TinyG, explicitly forcing inches with G20, verifying the system is in inches via $gun, set the X seek rate to 100 inches / minute, and reboot again. You’ll see the X seek rate goes to 3.937 inches / min, which works out to 100 (3.937 * 25.4).
Similar to what n7qvu says above, I’m just going to switch over to mm so I won’t have to deal with this problem, but I do want to make sure you’re aware of it.
Chris
{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"Loading configs from EEPROM","f":[1,15,0,38]}}
{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"SYSTEM READY","f":[1,0,0,960]}}
tinyg [inch] ok>
g20
tinyg [inch] ok>
$
[fb] firmware build 370.05
[fv] firmware version 0.95
[hv] hardware version 7.00
[id] TinyG ID 9H3906-XWP
[ja] junction acceleration 3937 in
[ct] chordal tolerance 0.000 in
[st] switch type 0 [0=NO,1=NC]
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[tv] text verbosity 1 [0=silent,1=verbose]
[qv] queue report verbosity 0 [0=off,1=filtered,2=verbose]
[sv] status report verbosity 0 [0=off,1=filtered,2=verbose]
[si] status interval 100 ms
[ic] ignore CR or LF on RX 0 [0=off,1=CR,2=LF]
[ec] expand LF to CRLF on TX 1 [0=off,1=on]
[ee] enable echo 1 [0=off,1=on]
[ex] enable xon xoff 1 [0=off,1=on]
[baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
[gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
[gun] default gcode units mode 0 [0=G20,1=G21]
[gco] default gcode coord system 1 [1-6 (G54-G59)]
[gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 0 [0=G90,1=G91]
tinyg [inch] ok>
$x
...
[xvm] x velocity maximum 19.685 in/min
...
tinyg [inch] ok>
$xvm=100
[xvm] velocity maximum 100.000 in/min
tinyg [inch] ok>
$x
...
[xvm] x velocity maximum 100.000 in/min
...
tinyg [inch] ok>
{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"Loading configs from EEPROM","f":[1,15,0,38]}}
{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"SYSTEM READY","f":[1,0,0,960]}}
tinyg [inch] ok>
g20
tinyg [inch] ok>
$gun
[gun] default gcode units mode 0 [0=G20,1=G21]
tinyg [inch] ok>
$x
...
[xvm] x velocity maximum 3.937 in/min
...
March 20, 2013 at 2:51 pm #3896aldenMemberI posted after you posted. I’ll leave my post below the —— and address your issue.
– Units are not saved. All internal units are in MM. The units mode is only used to perform conversions. See —- More post ——, below
– Issuing $gun only tells you what the default mode is set to. It doesn’t change anything
– I will verify your procedure and diagnose your case. I think it looks like a bug – so I’ll fix it.
Alden
——- More post —–
I think I need to work on the documentation. Here’s what I suspect is happening.
All TinyG’s internal values are kept in mm. This is true for Gcode positions (X, Y Z), as well as for settings. If the Gcode UNITS mode is MM (G21), then all input is accepted as MM, and everything is reported in MM. If you change to Inches mode (G20), then all the positions and settings are inpout as inches and displayed as inches. These values are converted to MM on inout and output. Internally, they are all MM.
To illustrate this try the following:
G21
G0 x0
G0 x25.4
?
G20
?
You will see the X axis at 25.4 mm in the first status display, and 1 inch in the second. The command line prompt tells you what units mode TinyG is in.
If you want to enter your settings in inches mode be sure the board is in inches mode. Same goes for MM. Ge aware that a g20 or g21 in a Gcode file WILL CHANGE the mode of the board. Like Gcode says it should.
Now for the power-on default settings. If you have $gun=0 the board will power up or rest to inches mode. If you have $gun=1 it will be in MM mode.
Please try this again and see if it works.
Thansk
Alden
March 20, 2013 at 3:07 pm #3897cmagagnaMemberHi,
I tried this. Same result. Please see above. I understand everything is being saved in mm etc. but the problem is if I specify a parameter (e.g. X seek velocity $xvm) the value is being saved but not converted.
I’m doing everything in inches. I reboot the TinyG and explicitly type G20 and $gun=0. The TinyG is reporting “[inch]”. I set $xvm to 500. The system now uses 500 inches / minute, and if I do something like “G0 X5” the X axis moves 5 inches at the correct speed (about a second). So far so good.
Now I reboot. Everything’s still in inches. $gun still reports 0, and the TinyG prompt is still “[inch]”. $xvm, however, is now 19.68 inches / minute. Even if I issue “G20”, when I do something like “G0 X5” the X axis moves really slowly (because it’s only moving at 0.3 inch / sec).
So yes I believe everything in the base code etc. is working fine with regard to inches / mm, but I believe there’s a bug in whatever code writes the parameters to EEPROM. I believe the “500” is being saved verbatim; since the units aren’t being converted on reboot the startup code is reading the “500” and assumes its mm, which is 19.68 inches.
I hope this helps.
Chris
March 20, 2013 at 6:34 pm #3899aldenMemberThanks for the diagnosis. This will make it easier to fix. Technically the EEPROM ins unit-less, and assumes all parameters are in MM. So what’s probably happening is the the input conversion is not working properly and it thinks the inches value you are entering is actually a MM value, which of course it is not. Then it sores the value as an incorrect MM value. I’ll check this out.
[UPDATE]
Most definitively a bug. Thanks for pointing it out. I’ll post again once it’s fixed.
March 21, 2013 at 6:24 am #3904aldenMemberThese items have been fixed in 370.07 currently on the master branch
– Fixed problem where settings entered in Inches mode are saved to EEPROM incorrectly
– Changed help text to agree with changes in 0.95 release
March 21, 2013 at 4:53 pm #3905n7qvuMemberJust loaded 370.07 and it seems to be working great. No issues with saving ‘inch’ parms.
This was my 1st use of my new MK programmer. I loaded the xboot.hex and then TinyG.hex via Studio 6.
Only issue I had was when loading xboot, the lite kept flashing and the screen header indicated “device programming”, so I thought it was still working. Finally gave up and read the bottom of screen that said Verified OK. Loaded in TinyG, lite flashed 10 times and all is well.Jerry
March 25, 2013 at 10:22 pm #3952cmagagnaMemberHi everybody,
I just got my board back from Synthetos, now with the bootloader and version 370.08 of the code.
I haven’t had a chance to hook it up to my ShapeOko yet, but I can verify both the limit switch bug and the saving parameters in inches bug are now fixed.
A special note of thanks to Synthetos for both the quick bug fixes and the immediate turnaround in upgrading the firmware on my board (they got it Friday; I got it back today). You guys are great!
Chris
-
AuthorPosts
- You must be logged in to reply to this topic.