Edward

Hi Alden,

– I believe that I can reproduce the issue whether the power supply is connector or not, but the initial occurrences were both after I had physically moved the machine, so power supply definitely disconnected.

– EStop breaks the +24v. I understood from the shapeoko forum that, with the arduino & Grbl at least, breaking the -ve could allow power back through the USB line? Please see this link for a diagram my wiring set-up.

– By ‘variable amounts of movement’ in my earlier post, I meant that it might take a dozen or more physical moves of various speeds to trigger the flash loss. It is not instant or entirely predictable, but, even if it takes a couple of minutes, I believe can reliably cause the problem. Regarding your first question, the power supply was connected but Estop down during my tests of this from yesterday.

– Chip is: ATXMEGA192A3

Let me know if you need anything else,

E

• This reply was modified 11 years, 4 months ago by Edward.

Hello all,

Just to update on this as it is looking pretty certain that the problem is down to my code and not the TinyG…

I had an update loop that was *supposed* to issue commands one at a time, waiting for the command acknowledgement in between. It was also intended to keep track of subsequent (but asynchronous) status reports following command completion. However I became suspicious yesterday that I had probably not been taking account of the feed hold (!) and queue flush (%) commands correctly in my own command, acknowledgement, report cycle, and this could cause me to get out of synch with the TinyG. A quick test last night seems to confirm that I can reproduce the problem described above, but only when I send rapid commands without correctly waiting for an acknowledgement in between. I hope this information might still be useful if other encounter a similar issue.

Cheers

E

Just found this: https://github.com/synthetos/TinyG/wiki/TinyG-Feedhold-and-Resume

So modifying accordingly.

Cheers

E

@mcgyvr – Thanks for the link, I’ve created something similar in JSON that I send on initializing and first connecting. This does indeed resolve the practical problem, I am actually interested in understanding and building the firmware for myself though, and I thought that fixing this for my specific setup would be a good first exercise.

@Alden – That would be great, Riley pointed me at the Edge branch in a different thread and so I assume that this is the one to keep up with? Just for the record, is my basic premise even correct that swapping out the included headers is the correct way to build a custom firmware specifically for the shapeoko?

Cheers

E

Just a quick update – re-flashing the firmware from the default build on github (TinyG/firmware/tinyg/default/tinyg.hex?) has restored the board to its happy, non-blinking, former self.

It also caused me to take the plunge and have a go at building the firmware from source anyway, but I will post about this separately to avoid moving off this thread’s original topic.

Cheers

E