Hi I've been trying out the TinyG v2 on an arduino due+gshield for controlling


I’ve been trying out the TinyG v2 on an arduino due+gshield for controlling my 3040 cnc and have a few issues.
I understand that it’s still very much in development but I’m hoping there’s someone else with experience with this kind of setup who could clarify a few things.
I’ve managed to get the default chilipeppr logo to run perfectly, but it seems that feedhold causes the Due to lock up and i have to restart both it and the SPJS.
This also kinda breaks the jogging since it also sends the feedhold command.
I’m guessing that the auto-levelling might be doing this aswell because it also locks up at first contact.

So I’m wondering if anyone can confirm if this is a known issue, and if it’s related to chilipeppr or a firmware issue?
I’ve tried both the master and edge branches of G2 with the same results.

@Alden_Hart pinging Alden to see if he has thoughts on it. What version of firmware are you using on the Due?

I’ve tried both the most recent master and edge builds on github so that would be 078.06 and 71.04.
I’ve been reading up on the G2 wiki and I’m starting to suspect that it might be an issue with the dual usb endpoint scheme.
If you have a look at the last section on this page:

@Rob_Giseburt may have some ideas as well. I may have to tweak SPJS to take into account the dual port, but that’s a lot of work.

Hi @Mattias_Wiik . We are currently working on the feedhold functionality in the edge-io branch, which is in very active development right now.

Our goal is to have it work like v8 as far as compatibility goes as much as possible when opening a single port. There are clear advantages to two-port mode, but we have to have a migration path.

Watch issue 41 on github ( https://github.com/synthetos/g2/issues/41 ) and we’ll mark it closed when we feel we have it working.

Also, thank you for you’re interest in our project! It’s very encouraging!

@jlauer I imagine that It’s a bit more than a simple tweak. Apart from this i just have to say you’ve done a great job on chilipeppr :slight_smile:
Thanks for you comments @Rob_Giseburt , you’ve confirmed that it wasn’t some small stupid eror on my part.
I think I have a rough idea on the issue now.
I will be following your progress with great interest.

Well, here’s what would need to be done to better support the dual port. When you connect to the first port from CP, CP would have to detect that you’re using a v9 or G2. Then it would have to guess at going up one port to auto-connect to that. Going up one port is tough because it’s called different things on different OS’s. So, to go up one port on Rpi would be ttyACM0 -> ttyACM1. On Windows going up one port would be COM4 -> COM5. Now, I could instead just have the user pick the 2nd port and that would likely be needed anyway, but it sure gets a bit non-sexy to ask the user. Steve Jobs would NEVER ask the user for the 2nd port.

Then you have to give some new pubsub signals to the workspace so other widgets can decide intelligently which port to send to. The real widget that would have to understand this is the TinyG widget. It would have to watch everything now and decide when to yank out of the stream. This means the TinyG widget would have to intercept all /ws/send signals. It does not do this right now, so that’s a switch.

Then, once the 2nd port is figured out, you’d have to redirect all Gcode to the 2nd port and leave alone the critical Gcode for the 1st port. So, you’d have to filter everything and decide to send !~% to the 1st port. That’s not too bad actually, but is some extra branching work.

@jlauer Let’s talk about this more. I think it can be made much simpler, though.

@Rob_Giseburt on my Rpi2, if I reset the G2 I get different ports when it comes back. I go from ttyACM0 to ttyACM1, but on reset it ends up as ttyACM1 and ttyACM2. However, today it ended up at ttyACM0 and ttyACM2 after a reset. So, truly, these dual ports are going to be hard to deal with.

Could you not do a delayed opening on the second port? For example, Port 1 comes up automatically, but port 2 only enunerates after connecting on port 1. CP and other clients can then do a diff on the com port enumeration to discover the second port reliably.

It’s a matter of looking at the metadata for the port. The host OS has the serial number and vendor/product IDs. It’s not possible to tell on FTDI from another, but you can tell that both ports of a G2 have the same serial number. It doesn’t matter which order you open them in either.

On windows this is not so easy, on OS X it’s a little easier, and it is dead simple on Linux. this is a function that the serial port module in the language you’re using (go, in this case) should handle for you. The ones in Python and node both handle these, so there is reference code out there.

However, as I said, we’re working on making single port mode more compatible, so there’s a clear migration path with less pain.