- This topic has 13 replies, 4 voices, and was last updated 10 years, 4 months ago by
.
-
Hmmm, the only thing I see on quick look is that Flow control,$ex, is set to off. Probably OK for line by line cli entry, probably not for sending Gcode files such as hello world.
Set $ex=2 (for RTS/CTS) and set Coolterm as well.Can you dump all the tinyG parameters with a $$ command and put the results in a text file, post a link to it (dropbox or similar)?
Direct posting to the forum is hard to read. Result should look like this
Your configuration is this (?)
Motor 1 – X axis
Motor 2 – Y axis
Motor 3 – Y axis reverse
Motor 4 – Z axisTedB
1. Something is very wrong with your confgs – compare yours to thisThose values may not be correct for you, but your file has numerous ‘nan’ entries that are bogus.
2. Try this: Reset tinyG (reset button) then in Coolterm enter $defa=1. This will reset the tinyG to factory defaults. Likely it will reset some values that you entered for your machine, they will have to be reentered. But should you continue to see ‘nan’ when you do a $$ dump, then you likely have a defective unit.
ReferenceAssuming 2. works OK, read on:
3. Are your Limit switches really NO? NO is susceptible to noise. Try running your job with Limit switches disabled.
4. I assume you reversed the wiring on one of your Y motors, because the config says both motors 2 and 3 are set to the same polarity.
5. Your Coolterm settings “look” correct to me, but I am not a Coolterm user.
6. I would leave $?pm=0 for all motors. Should work, dissipates a little more power but that isn’t you issue at the moment.Good Luck
Thanks for the detailed information. Many points to cover, so bear with me. (this message overlapped Carl’s – above – so there is some duplication)
First, your $$ settings are messed up, somehow. You should not be seeing the word ‘nan’ anywhere, and way too many things are set to 0. I recommend resetting them to defaults by issuing $defa=1. This will wipe all your settings and you will need to reset, but I think it’s necessary.
Next, I recommend that you update your firmware to the latest edge build – currently 435.10. It can be found here: http://synthetos.github.io/
Third, the Coolterm settings look OK, as far as I’m familiar with windows. You do, however need flow control updated to XON. You currently have it turned as RTS/CTS and turned off on the board (may be a settings problem). I have updated this page with (hopefully) clearer instructions:
https://github.com/synthetos/TinyG/wiki/Connecting-TinyG#establish-usb-connectionFourth, some other points on the settings:
– Try dropping junction acceleration [ja] down from 2M to 200,000, then crank it back up again once things are working.
– Set JSON verbosity [jv] to 3 (default). THis will allow you to see startup messages
– Set Text verbosity [tv] to 1 (default). Otherwise it’s silent.
– Set flow control to XON [$ex=1]
– Note that on the new build the power management settings are different, as are some others. See here for reference:
https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97Once you have done these things try your tests again.
Separately, Should I assume that you have previously entered a feed rate (e.g. F500) before the G2 X0 Y30 I0 J15 command?
The motor timeout should be working on the 435.xx builds – it does not work in 412.01
I have not had a chance to look at the max velocity issue but will check that out as well. I believe this is not a problem in the edge builds, but would like to verify.
Good progress. Some points:
– Thanks for the pointers to add DTR to the RTS/CTS setup. We will make that change in the wiki documentation.
– As for flow control, we’ve found the AVR can process things as fast as the host can send it, but the Gcode execution occurs in real-time and is what sets the pace that Gcode blocks can be received.
– If you are blasting down sequences of $ commands (configs) it’s advised to delay about 30ms – 50ms between each one. This is because each config item (that changes) causes an EEPROM write which takes about 20-30ms, during which time the AVR cannot receive any serial input. So communications errors can occur in this interval. Coolterm has a setting to do an end-of-line delay.
– We have seen settings get corrupted in extreme cases where motors are moved rapidly while the board is unpowered. There was enough back EMF to get back into the switching power supply and power up the MCU. By setting the MCU config fuses to the correct brownout level any ill effects were prevented. We made this change initial chip setup about 2 years ago. We have not seen this error since then, but are now sensitized to it. That doesn’t explain why you had a corrupted config, so I’d consider that issue still open.
- You must be logged in to reply to this topic.
