Are they any known issues with CP controlling TinyG2?

Are they any known issues with CP controlling TinyG2? (complied from edge branch & using the ?v9=true in the URL)

It connects, I am able to pull/change the config. But when I attempt to send any gcode the controller sits at 'New line length: 1, buffer size increased to:80’ in the console (in serial-port-json-server) And nothing happens.

I would skip using the ?v9=true. All that does is adjust what settings are sent to the TinyG because of an EEPROM issue. On my v9 I don’t have that issue so skip that. If you watch my Touch Plate video that is actually running on a v9 so it works well, but given that v9 has 2 serial ports, there are weird issues I see when using Feedhold (!) so I try to never use it. I tend to have to restart SPJS a lot when using v9. So try that.

And this applies to G2? (The ver. that runs on a Due) nixing ?v9=true behaves the same. Pulls config. Config is editable. When attempting to send gcode nothing happens.

@Alden_Hart @Riley_Porter_ril3y may have a better idea. I have not run G2 yet on the Due but intend to soon. The v9 I’m using is basically a Due with exact same processor. I get two serial ports and that is key. Do you get 2 serial ports on your Due when running the G2 firmware?

Yes. ttyACM0 & 1.

I would reset your Due and then restart SPJS again. The connect to ttyACM0 and it should work. Truly, I restart SPJS a lot with the v9 to get it to work. Remeber, you can restart it from ChiliPeppr with that red double square arrow icon button.

tinyGv9 should be thought of as an application specific board built around a DUE reference design, so they behave more the same than different. As you know from building G2, you have to specify the Platform and settings when you build. Can you maybe post here the options you built with? Did you adjust the tinyG2 parameters (all of them) to match your machine? Should we assume you are using a Gshield, or something custom connected to the DUE.
I can report that G2 build 71.04 (current master)ran a quick Gcode on both a tinyGv9 and on a DUE, but there were no steppers attached, which should not matter.
What OS did you build on and what build did you get, 75.?? or ?

Compiled both in linux and OS X (with Xcode) I was not sure if the issue I was having was due to the compile method. During my troubleshooting process I’ve used the defaults and get the same behavior in CP.

I’ve used the latest ver. in the edge branch as stated above. (git pulled as of last night @ 1am)


I am using a custom shield. The pins and default configs have been changed to match. But at this point that does not matter as It should be able to attempt to process the gcode with nothing attached.

And having reread John’s ‘reset spjs a lot’ comments (I agree), remind yourself that resetting the Due (or v9) will require resetting all parameters again. If you have a good set of parameters from prior use (such as tinyG), I would suggest creating a custom settings file which you should start from the included /settings/settings_shapeoko.h file. Here, for example, is my file I offer NO GUARANTEES that this is appropriate for your machine. If you compile with your ‘proven’ machine settings, then a DUE reset will not be as invasive.

Right. But It needs to process gcode commands first before I even get that point. As of now. I can read/write the config via CP. But sending gcode does nothing.

I now configure my v9 from the cog wheel icon button next to the ttyACMO in the SPJS widget inside ChiliPeppr. Here’s my settings I pasted into that “Startup Script” dialog box.

(X axis is motor 2)
(Y Axis is motor 3)
(Z axis is motor 4)
(A axis is motor 1)

Might be time for you to post a video of the problem. I have mine working pretty darn well, albeit lots of resetting to get it “unclogged” which it feels like yours is clogged.

I placed my settings in the firmware before I compiled it. With-in CP when I ask it to show the config. Those values come back correct. The issue when I send any gcode to it, It does nothing.

A quick heads up - if you built the current G2 Edge with Linux and downloaded it to Due, you may have created a brick. There was, a week ago, an issue with the linux based cross compiler that would build a bad G2.bin.
Also, I don;'t understand your comment that Gcode ‘needs to run before that point’, of course I don’t know what ‘that point’ is.
If tinyG2 won’t connect to spjs and report a build number in the TinyG widget box on CP, I don’t think trying to send Gcode is going to help.
And John, what build is working well for you on your v9? There are a lot of things going on in build s >71.04 , at least for me.

As always, we were typing at the same time.
Do you see the tinyG2 build number?
My sanity test for a connection is a quick $ command in the serial port console (not the spjs console). A short dump from tinyG2. If you can get that far, then Gcode should be safe

… CP see’s the Due. As I said, I can pull the settings from the TinyG2 and make changes. $H, $$ all work as it should. So connectivity is there. When attempting to send any gcode (mine of the example ones provided in CP) nothing happens.

Compiling and flashing is Linux worked fine for me. As I said. I can connect to it. Just when it comes to sending gcode. It does nothing.

By the way, when the dust settles, can you report what you built from (Edge, I believe) and what build # you got (that started) and what OS it was built on? The Linux compiler issue may now behind us,

Maybe look in my Touch Plate video and look at the shots of CP to see what firmware I’m using. It shows it in the TinyG widget in small font.

I have. You are running 74.03. Mine reports 75.02. Is that the issue? The FW is too new?

75.02 too new? for sure it does not have a lot of test time on it.
Can your jog your machine from CP? I believe that is a locally generated string of Gcode (John can confirm)