Hello! I'm working on a retrofit of a 1998 Isel DaVinci (educational model) benchtop


I’m working on a retrofit of a 1998 Isel DaVinci (educational model) benchtop CNC router. I went with the TinyG G2 (Due + gShield). I connected the motors to the board, running off a benchtop power supply at 28V. I loaded the latest G2Core firmware with Bossac. And…nothing. I think. I’m almost certain that at least one motor sort of twitched, but with the noise of kids running around I can’t be absolutely certain. It definitely didn’t do much.

I’ve never done any of this before. I have never successfully used ChiliPeppr. So I’m not sure if I’ve missed a step. And looking at the wiki pages and so forth I don’t think I’ve seen a straightforward list of instructions in order. More like lots of info on lots of pages (which, of course, is typical when there are so many variables involved).

What is the appropriate troubleshooting/diagnosis process for this? I can’t tell if I’ve done something wrong with the wiring, the programming, or if I’m just using ChiliPeppr wrong. I can say that where I see in John Lauer’s youtube videos that there are two ports shown, I only show one. What does that mean? Sorry if that’s not enough detail there, but this is already pretty long…


Are you sure you have a due? I thought they always had 2 USB ports on them. One native and one ftdi.

Sorry, I should have worded that better. I mean in ChiliPeppr your videos always show two ports identified. Mine only shows one. And I’ve tried with the Due connected on either of its USB ports. Here’s a screenshot from one of your videos (the one about being able to program through ChiliPeppr now). I’ll post a screenshot of my own instance in the next comment.
missing/deleted image from Google+

Note that only one thing is showing up. Is this a problem or do you just always have multiple devices connected when you’re doing your videos?
missing/deleted image from Google+

Here’s one from your almost 2 hour hangout with a user. If memory serves this was his view on his own MacBook? Presumably he only had one device connected.
missing/deleted image from Google+

That means you are in programming mode. Reset or program again to get out of it

Well, that explained that, but it disproved my guess that it had something to do with my problem. I still don’t get any movement from my motors. But they did “twitch” when I reset the board. Again, is there an ordered list of instructions somewhere to make sure I’m not skipping a step?

What version(build) of G2core have you loaded?
The most recent Edge build, $fb=100.26, now only establishes one virtual USB port, which on linux appears as /dev/ttyACM0.
The DUE of course still has two physical usb ports, the programming port and the native port.
If you are running 100.26, there are several changes from prior builds, read the readme on the code wiki carefully.

The twitch on reset you mention is likely the motors energizing, then timing out after the $mt interval.
If you are in fact running $fb=100.26, did you compile it for Gshield?

I had used 078-edge following the instructions at https://github.com/synthetos/g2/wiki/Flashing-g2core-with-Windows, but just now reprogrammed it with 087-edge through ChiliPeppr (no change). That’s all that is shown in ChiliPeppr. http://synthetos.github.io/g2/ shows 078.03. Not sure where you are getting 100.26??

Again, I am VERY new to this. I am trying to follow directions, but they are spread out across multiple pages on multiple sites. The primary question I am trying to find an answer for is: Is there a comprehensive guide for setting this up somewhere? Everything in one place, in order?

Alternatively we could dive into the ultimate question: Why am I not getting any movement from my steppers after following what seems to be everything I can find from pages like those above, various YouTube videos, etc.? For reference I have since switched to using a standalone NEMA 23 stepper and dedicated power supply, removing as many variables as I can (including the fact that I’m trying to retrofit an older machine with little circuit boards in each motor enclosure which adapts the four control wires to eight). Absolutely the same behavior as when I was connected to all three motors on the actual machine I’m trying to set up, with a test bench power supply. What in the world am I doing wrong? By all indications I just program the g2 and it just works. I assume I’ve missed a step somewhere, but I can’t find anything resembling a comprehensive list of instructions to verify that.

Thank you for your help.

“…I just program the g2 and it just works…”
I doubt many would agree that your observation is correct, it really isn’t that simple…
That said, many experienced tinyG (and other platform) users have leveraged G2 (now known as G2core), it’s flexibility and enhanced performance to build powerful machines.

G2core is a soft/firmware development still very much under development. It started by replicating tinyG functionality and porting it to ARM based controllers, e.g. the DUE. There is significantly more compute power and hardware I/O capability on these evolving ARM based machines that the evolving G2core architecture will support.

There is no one step-by-step for getting started with G2. I’d suggest you review the tinyG wiki, https://github.com/synthetos/TinyG/wiki , particularly the getting started pages. Then reread the sections of the G2 wiki to see how they fit into the “tinyG way” of getting started.

There is a significant difference between tinyG and G2core that you need to realize up front. When you suggest “I just program the g2 and it just works” it sounds like you may have skipped the Configuration steps. Both tinyG and G2core have a compiled-in set of default parameters that I doubt match your target machine. tinyG hardware had on board EEPROM (flash-like memoy) that stores your parameters, the DUE platform does not, you will see several references to the lack of " parameter persistence ". This means that every time you reset the Due, you need to reload the parameters Chilipeppr has some support for doing this, I would suggest also you consider compiling your G2 binary with a default set of parameters specific to your machine.

Versions - Have a look here, the Edge github code base pages https://github.com/synthetos/g2. The readme about the current state of G2core has some good info.
I would suggest you begin by using $fb=78.03 from http://synthetos.github.io/g2/ . It is built for DUE + gShield, it does work but is VERY out of date. The 87.xx build on Chilipeppr is one I believe JohnL built and also works. Make sure you get the version for the DUE, not tinyGV9, which was a pre-release hardware platform if you choose 87.xx.
Version 78.03 should provide basic move motor functionality, once the parameters are properly set.
There are several versions of $fb=100.26 available here, https://github.com/synthetos/g2/releases, but not one for DUE+Gshield, so you would have to build that.

I have no familiarity with what you are doing w.r.t. mapping 8 wire motors to 4 wire drivers, but be mindful that tinyG and DUE output 3.3V logic. Many external drivers require 5V logic.

If you need to be convinced that G2core can be made to work for you, head over to the Qx forum, https://plus.google.com/communities/110852928951643236736. Lots of folks there building with/on G2core.

Good Luck with your project

Thank you for your response. The driver boards I was talking about do not have any logic. It’s purely wire routing. 4 wires from the old control board go into a little board in the motor enclosure (actually 4+2 out of the old controller, the other two being for the limit switch). 8 wires come out and go to the motor. No other components on the board. I just mentioned it as part of why I was trying a standalone stepper without anything else attached for the sake of eliminating variables.

Just to be clear, I was somewhat hyperbolizing when I said that “you just program it and it works”, though that is very much how it’s shown in numerous youtube videos, when any programming is shown at all. I share now what follows just for a view of what this experience has been like for me. Having worked with many developers as a project manager I know that developers see things very differently from how users see them. I hope the perspective helps a little.

There’s no doubt that it can be made to work. I am frustrated (not with you, just with the experience) because, when I asked around about recommendations for driving this old machine over USB or ethernet, many people recommended various forms of gShield/TinyG/G2. I expressed that I wasn’t interested in the additional learning curve of an Arduino system if I could avoid it, as I already have plenty to learn with the entire CAM/gcode/CNC workflow, etc., but I was repeatedly assured that it’s just no big deal, you just load the preassembled firmware and run with it. What I saw on YouTube videos certainly seemed to confirm that, and then in my searching I found John’s blog post comparing grbl, TinyG, and G2, and found his arguments there quite compelling, so that’s what I ordered.

As it turns out my first instinct was correct. It’s just not that simple. Now I’m out a chunk of change, all the time waiting for the boards to arrive, and the time spent trying to figure out how to make these work. Just so I could avoid having a big tower in my crowded single car shop. I have a full complement of metalworking and woodworking equipment there, so there’s just not room for anything more than necessary. This seemed like the perfect solution. But it has proven to be more of a PITA than just getting a Gecko and using an old tower and Mach3 would have been. The time this has taken has cost me more than it would have for the Geckodrive G540, BOB, and Mach3 license. Of course I would be stuck with Mach3 on ancient hardware, but at least I would have a working machine instead of just questioning looks from my concerned wife.

For now take it as feedback that the workflow is not clear for new users. I am a hobby machinist, I have worked as a project manager in a $20M software firm, I have set up complex systems of many types including combined Linux and OSX networks for ripping and printing (including the most complex color management system I have ever heard of) in a large format print shop, and I generally know my way around computers and machines. I certainly consider my skillset sufficient for this kind of project (setting up, not developing) but I find the scattered information thoroughly frustrating. I have a very limited amount of time to spend on this a few evenings per week and I end up forgetting much of what I’ve learned by the time I get back to it. The documentation leaves much to be desired for those outside the development community. For instance, at no point in my pre-purchase research did I get the feeling that the G2 “is still very much under development”. A now 2 year old blog post promoting it as the best solution in this category certainly didn’t suggest anything remotely like that. http://chilipeppr2.blogspot.com/2015/

I think I would find this “read everything on site X and then compare it with everything on site Y, and some blend of the two is what you need here” approach to be perfectly reasonable for a roll-your-own-controller system. But I was under the impression (again, pre-purchase) that I was buying a commercial product that was ready for primetime.

Again, just feedback to be applied if considered useful. Sorry if it sounds like pure complaint. I really do mean to help for the sake of others in the future. Thanks again for your detailed response, and I will go over those pages again to try to put together what I’ve missed.

Understand, I was in a similar place when I got my first tinyG. At the time, Mach3 was still printer port only, so I never researched it further.

Back to where you are at.
G2core/DUE/Gshield plus $fb=78.03 or 87.xx should look a whole lot like tinyG setup, with the exception of the parameter persistence issue. I would start there, with the NEMA23 motor jut to get up and running.
Since you are obviously able, I would recommend a sidebar project to get a fw build capability in place for G2. The guidelines in the G2core Wiki are quite comprehensive.
Once up and running, key an eye on $fb=100.26 and later. it introduces a lot more features and I/O capability, but it is quite new so will have a learning curve for everyone

Good Luck

By the way, rereading a bit, $fb=78.03 should be showing up as Two COM ports under Windows, or /dev/ttyACM0 and /dev/ttyACM1 on Linux (and Mac, I believe). You might need to stop and restart SPJS, not sure.

After successful loading with bossac, did you move the USB cable from the programming port to the native USB hardware port?

Reset the DUE if moving the programming cable didn’t.
You should see a two second or so flashing heartbeat from one of the LEDs near the native USB. That heartbeat runs continuously if G2 is running.

Yes, I’ve tried operating in both cable positions. No luck.

I don’t see any such “heartbeat” behavior for any length of time. I have reinstalled several times. Neither Bossac manually nor ChiliPeppr have given me any sort of error messages. It says it completes, the lights on the boards go out then come back on. I can switch between the two USB ports and hit reset buttons and restart JSON server and computer and browser and refresh JSON server and anything else I can think of until I’m ready to throw the whole thing in the trash and I never see any sign that the board is receiving any data. This standalone stepper definitely energizes when I reset it, but that’s as close to movement as I’ve seen. Any sense trying the 100.26 if I can’t get motors to move in 87?

How do I tell if there’s something wrong with either of these boards?

I had a thought as I was reading the g2core wiki pages today that I should try the driver update when I got home. I was thinking that I had overlooked it, but then realized that my wife’s computer (that I’m using until I decide what will be running this thing permanently) is on Windows 10. I tried to install it anyway but couldn’t find a way around the “driver is not signed” error. And the wiki page says it’s not necessary anyway.

I just installed Universal GCode Sender. It recognized a “TinyG” on Com7. When I connected to it the LED on the Arduino started flashing. It’s about 2.5 seconds on, 2.5 seconds off, continuously. Does that mean that the firmware should be working? Because when I go to Firmware Settings it says, “No firmwares found”. Not sure if that’s just an incompatibility thing or if that means that the firmware is not installed. But the light thing is flashing, and ChiliPeppr indicated that it installed just fine. Lots of mixed messages and confusion here. :frowning:

The blinking 2.5son/2.5secoff of the Rx led says G2 is running.
You should be able to connect via the Native usb port.

I am connecting with putty (linux), but for some reason am unable to get Chilipeppr to connect. For you, running Win10, this would be same as connecting with CoolTerm or UGS.

I pulled the 87.01 binary from Chilipeppr and loaded it manually (CLI) onto my DUE, which is just a DUE, no Gshield, powered via usb connection. The name of the file is TinyG2-gShield-087edge.bin, so that says to me JohnL built it for the DUEplusGshield pinout, which is what you need.

I could not get the Chilipeppr firmware loader, under SPJS v1.94, to install 87.01 directly. This may be an issue with the Linux build of SPJS 1.94, I have seen this with prior versions of SPJS, where Win10 worked OK but Linux did not.

After successful bossac programming, the final response from bossac is “CPU reset”. I find the sometimes does not get G2core started. Hit the DUE reset button. You should not need to be logically connected (UGS, CP, etc) to the DUE for G2core to be running and heartbeating

I am assuming you are running SPJS on your Win10 machine, not a separate machine (e.g. a RaspberryPi).

“…when I go to Firmware Settings …”
I believe UGS was built around GRBL, it does not speak tinyG control language…
You access tinyG from the UGS command line.
A ? plus carriage return should respond with several lines showing current position of machine.
A $ plus carriage return should yield a short parameter listing.
A $$ plus carriage return should yield a complete parameter listing
You can also enter G code commands on the CLI.

UGS does send Gcode files to tinyG just fine.

My current view is that 87.01 is what you should stick with, properly configured you should be able to move motors.

As far as I can tell, there is no pre-built 100.26 release for DUE plus Gshield configuration. These other builds support different physical pin assignments to the ARM cored microcontroller. At least one version of 100.26 runs on the DUE logically but probably does not properly connect to the Gshield board.

Debugging hints

  1. when you start SPJS, add -V to the command. SPJS will send a more verbose messaging stream to the console in which SPJS started (assuming you start it from a DOS window)
  2. Keep an eye on your Win10 Task Manager. it is possible to end up with more than one instance of SPJS running, which adds confusion and port access issues.

An now, magically, CP is connecting for me as well.
A refresh of the CP window seemed to do the trick.

Hey, Jon, did you ever figure it out? I’m running an 1990 ISEL XYZ gantry. But with a TinyG, whose wiki is more straightforward and detailed in setting up.

You might try testing your extra motor with its procedures, tailored as needed, to see if the motor energizes. I have ISEL motor wiring diagrams as well, if you’re interested, which helped going from eight wires to four.