alden

We think this is tgfx; a limitation in the JVM where garbage collection kicks in. The equivalent of a memory leak. I would not expect the behavior to change by adjusting the TinyG board. I don’t think the problem is there.

I found the cause of the lockup. I posted a fix that is still under test if you are interested in trying. I’ll push to edge once I’m satisfied with it.

https://www.dropbox.com/s/l43pohzcgchhhap/tinyg_435.14_dev.hex

It’s pretty low-level what was going on. Certain chips in the AVR Xmega series require a work-around to write to EEPROM (or any non-volatile memory, also including FLASH). This requires all interrupts to be turned off for the duration of the write, about 20-30 ms. The G10 function is therefore written to defer persisting the changed coordinate offset values until after the machining cycle, as this would stop the stepper interrupts and hence the motion. But due to a change in the way I run cycle ends they were being called from an interrupt during the finalization of the machining cycle, causing a deadlock. I moved the persistence to the main controller loop as a callback and the problem went away. Thanks for finding this.

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.

• This reply was modified 10 years, 4 months ago by alden.

I think you have found a bug in the way G10 works. The work-around for now is to use the $g55x=… format instead, which does the same thing.

Just confirmed that setting the max velocity does indeed work (e.g. $xvm=1000), so I suspect that is also related to the problems in the settings.

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-connection

Fourth, 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.97

Once 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.

• This reply was modified 10 years, 4 months ago by alden.

Thanks for trying this out. Please let me know if there are any other issues or observations. To assist in this I have moved this thread to here:

Testing Edge Builds 435.xx

Please use the new URL for any discussion related to the 435.xx series builds.

• This reply was modified 10 years, 4 months ago by alden.