First off, I’m super stoked to find ChiliPeppr, it seems like a very capable software and hopefully it will one day work great with my machine. Of course my use verb implies it is not working great right now, through no fault of its own I’m sure.
I have a Arduino Due paired with ma860h drivers running nema 34’s. I have wired the steppers to the Due using the TinyG2 pin-out diagram found here https://dl.dropboxusercontent.com/u/50261731/Wiki%20Work/DUE%20tinyG2%20pinout%200.2.pdf. At this moment in time I only have the “m1” motor connected, but all drivers are connected to the Due. For “motor 1” I have PWM2 and PWM5 hooked to PULS() and DIR() respectively on my driver through a 3.3V to 5V logic converter, with PULS(+) and DIR(+) hooked to a 5V source on the Due. ENA(-) is connected to pin 22 and ENA(+) to another 5V source.
On the software side this is what I have done so far and the results therof. After starting the JSON server I open the Tinyg workspace and program the Due as (Due + gShield ver. 087-edge). At this point I expected to be able to jog the X-axis to confirm everything was working but have not had any such luck. I was able to write a simple program in the Arduino IDE and run the same motor so I know that at least in that instance the hardware works. I also notice the motor cycle on and off when reprogramming the Due from CP, and I get RX blinking whenever I send jog commands, so this at least seems like a good sign.
I’m wondering whether I can just use the gShield firmware like I thought, or of if I need to make my own version somehow, or maybe something else entirely. I have attached a couple pictures of the setup and what my CP screen looks like after programming the Due. Apologies if I’m asking the wrong questions here but I’m kind at a loss for what to do next.
You may need to RESET Due after connection and if you see TinyG2 port in Serial Port JSON Server widget, try $ or $$ to display status information. $m shows motor related configuration. Once all looks OK, try jogging.
Sebastian, thanks for the input. I’m working from the Due native port now and CP is now recognizing it as a TinyG G2 (as you can see in the screen cap). If this is correct, I’m running into some errors? in the serial commands. As you can also see, things work momentarily but seem to stop (yellow check marks, I’m not sure what these mean although trying to figure it out). $, $$, and $m all return the same {“ej”:" "} line, again not sure what this means exactly but i got the sense it wasn’t right. missing/deleted image from Google+
They’re at version 100.18 or so of G2 and you’re at 87 according to that screenshot. I would upgrade and it will solve your problems. In old firmwares they didn’t support the TinyG v8 config commands that ChiliPeppr sends on startup, but now they do.
I updated to G2 version 100.19 and double checked I have the latest and correct version of JSON server. One thing I’m not sure is correct is that CP list the TinyG G2 on COM11 but SPJS says something about a BOSSA Program Port COM5? However, in CP looks like the g commands are at least getting through now? Also I’m now able to jog around the screen quite nicely. Still no motor movement however; it seems to stay in a low power mode (on with the shaft locked in place) the whole time unless i disconnect the enable at which point the power supply kicks into high gear and the motor jolts slightly (eventually it will get warm in this state due to the higher holding current I believe). I have also tried bypassing my logic level converters to make sure they’re not impeding the signal somehow; same results with and without. missing/deleted image from Google+
Due will show you Bossa port after power on, just reset, refresh sjps connected devices and you will see TinyG.
I had a quick look to the settings and found that sections of the default settings file are over-commented out causing some settings being not applied during compilation.
Finally I am able to see move and X/Y/Z coordinates updates in Chilipeppr.
So after more experimentation I found that if i set the buffer to “default” then reconnect I can get more information in the serial port console (see screen cap) and the $, $$, and $m commands return useful? information. I thought i needed to be using the tinygg2 buffer but maybe there is a reason it wont work? I also notice that if I try and change the motor or axis settings from the cog menu in CP then hit save, my jog commands stop working (yellow check marks and no viewer movement) until I restart. I also tried both the default tinyg and ?v9=true work spaces and as far as I can tell both give the same results. Lastly I changed the baud rate in windows device manager to 115200 to no avail or perceptible change. missing/deleted image from Google+
Your screenshot looks perfect, except the default buffer will never work. You must use the tinyg or tinygg2 buffer or you’ll overflow the buffer in the TinyG the moment you start streaming your Gcode. Are you sure your machine isn’t crapping out on the config commands being sent at startup? That’s historically what folks have seen as a problem, but those initial config commands are critical to get TinyG into the correct mode for communicating with ChiliPeppr. In the version you’re running I’ve heard the ChiliPeppr config commands are 100% supported now.
Cool. So using the tinyg or tinygg2 buffer this is what I get in the serial port window. Also shown in what my startup script is, not if it looks good or not? As you say, I had read that people were having problems there but I’m not sure how to tell? Sorry if this is rehashing something that has been explained somewhere before. missing/deleted image from Google+
Hey @Lucas_Sass in case you used the settins_default.h file of the source to compile, have you configured the motor and axis configuration?
if i remember right, there is “power management: MOTOR_DISABLED” and on the axis type “AXIS_DISABLED”.
you have to change that to get a physical movement.
I use something like powered in cycle and axis_standard. Have a look at the comment behind the parameter in the file.
Andre, if I use the default buffer then there are some values which are already set in the tinyg config menu (same as those specified by g2/g2core/settings/settings_default.h in the G2 repository). If I use the tinyG or G2 buffer these are all left blank by default so I have tried to enter some (realistic but somewhat arbitrary values at this point) and set the motors to powered during cycle. However once I change these values the 3D view stops moving when I jog and I get some serial port problems (g code stops sending? i.e little yellow check marks). Not sure why this happens or how to fix it.
My gut is telling me you are all set on the ChiliPeppr side and the firmware side, rather it’s your configuration settings for motors that’s giving you nothingness in the 3d viewer. Just a guess though.
This is now my conclusion as well. I haven’t done any configuration except to try and play with some values in the tinyG widget in CP. I have tried a number of firmware versions (shapeoko and othermill) which load up different values (visible in the tinyg widget) but haven’t done anything beyond this. There was another post (https://groups.google.com/forum/#!topic/chilipeppr/xHf4o225Bgk) with a setup that’s sounds very similar to mine (due + custom shield + external drivers) and also had the same issues. I assume I need to do some/all of these things? I’m not really sure how to go about creating a config file or how to flash from command prompt or SPJS, but i assume this information is out there somewhere? Feels like I’m getting really close, just a couple settings that need changed somewhere.
So reviewed all the setup instructions and started from scratch on a fresh computer (win10) and a completely stock Due (nothing connected). Ultimately it seems like there is some failure to successfully communicate with the Due. As previously mentioned the default buffer kinda works (returns settings when asked) but obviously is not functional. Switching to the G2 buffer I still get executed g commands but am no longer able to get info from the board for example any “$” command returns {“ej”:" "}. Using both the default and G2 buffer I am able to navigate in the 3D view port with the jog functions, but again, only the default buffer returns information after a movement. Using SPJS version 1.92, and and the latest 100.19 G2 build. Also I’m not sure if its relevant, but after I run SPJS (either via command prompt or just by starting the .exe from my desktop) I am unable to issue commands (as in type anything into the command line). I appreciate the help from the community, hopefully I can get this working.
Check if your Due is returning the r:{} JSON after you issue a command. That releases the buffer in SPJS to let it know it can send more commands. Sounds like you’re not getting it. To see it, you have to un press the funnel icon in serial port console.
Looks correct. I think they recently changed settings where text commands don’t return text responses. I think you can change that setting though. In the meantime, you’ll only get JSON responses if you don’t change that setting, thus you should turn that funnel off all the time to see them cuz JSON responses are filtered out for v8 users because they would overwhelm you otherwise. I think you’re working. Can you mill?
Unfortunately nothing yet. Still in the same session from above so nothing has changed in that regard. Super miffed atm, I just tried multiple drivers on the same axis to rule out any problems there but still nothing. Is there some reason not having homing switches could be a problem?
