Alright, thanks for looking into it! 
Actually it might not be a bug after all (or if it is is about the delta kinematics)
It might be related to your settings after all.
I noticed you did not change the step per mm and are using the default settings
Please recheck those settings and teste again ($100, $101 and $102). They should be set with the proper value for your printer.
EDIT: Nop I really think there is bug. I’m getting the same results in the virtual windows emulator HAL. I’m investigating.
Calculated the steps/mm properly and its 80 in my case, not 200, good call!
I just put the stepper steps in $100,$101,$102
Wait!! It works!
EDIT1: The grbl settings were messed up, i think that was the issue.
80steps/mm - corrected from 200 on $100 $101 $102
and 245 on $106
and 106 on $107
for some reason it cancelled $106 and $107 when i restarted the arduino
also the Zlimit seems to have stopped thinking it was probe Zlimit - EDIT3: happened once again, seems to be less frequent now?
EDIT2: $X went through!
G0Z1 commands does nothing still, green bar adds up
Until I fix the code try this…
Send your gcode commands with full coordinates.
Instead of G0Z1 send G0X0Y0Z1 an see if it moves. I tested this in a Arduino Simulator and worked.
EDIT: I thing I found the bug. I’m patching the master branch. From now on you can download and upload the master branch directly to your board. Just remember to modify the cnc_config. file to match your needs. This as the added bonus of already having the updated code for homing pull-of (setting $27)
EDIT2: By the way the full coordinate command should be only necessary the first time you power up µCNC.
EDIT3: Another way to fix the code with the branch you are using is by enabling option FORCE_GLOBALS_TO_0 on the cnc_config.h file. This is actually a strange error since the startup code usually sets all global variables to 0 before starting execution so this option “should” in theory be redundant…I’m glad I implemented it. 
So after $X worked but not G0X0Y0Z1, I turned off the arduino, and now when I try to connect it doesnt show the green text at the start of the status messages - image is the start of them as soon as i hit connect
Now I just restarted the arduino from the ramps button, disconnected the serial and reconnected, connected on OpenCNCPilot and
Part of the green text already went past, $X worked!
G0X0Y0Z1 didnt move anything but the command went through? Didnt add to the green bar
Btw i keep on unplugging the arduino to turn it off/restart it, should I be doing it some other way?
Added the
Connects fine, unlocks fine but no movement even with G0X0Y0Z1
You only unplug the Arduino if you need to do a hard reset. You can do it but it’s not necessary most of the times. The soft reset command (ctrl^x) (opencncpilot has a soft reset button that send’s this command) should do the trick.
About the command. After sending the G code command what position did OpenCNCPilot reported? 0,0,0 or 0,0,1?
Did you reuploaded the code with the main branch version? If so recheck the settings since the master branch settings map changed version and your previous values may have been reset.
wasnt using the master…
compiling the master rn with the delta kinematics and ramps14 board but it gives me lots of orange text
EDIT1: image
That’s odd…
I get a clean compilation
I’ll try in a clean machine and let you know.
By the way warnings are not problematic…those warnings you are getting are just some ISO standards warnigs (code formating) but the code can compile fine never the less. If you turn your warnings errors of on Arduino IDE preferences you should get a clean compile
noted!
Position seems to be still 0, 0, 0
In this case there was also a pre-compiler error but the code would compile anyway…moving on.
Try downloading the master branch and upload it. Set KINEMATICS, BOARD and just to be sure (although I patched it) enable FORCE_GLOBALS_TO_0.
Again insert your settings ($100, 101, 102, 106, 107, etc…). After this turn your power supply of and unplug the USB cable. Replug everything and try it.
First time I compiled it showed some warnings and the next time it was clean hahah
same as before, pos still 0,0,0 - green bar goes to 9/120
Hummm… Something is off.
I’ll show you. I’ve just recreated the steps I’ve told you. And I you can see my Arduino MEGA is outputing the steps (as shown in the scope).
So in theory it should work. And the other odd thing is that on yours the steps are not even being generated( as it should travel to 0,0,1 on opencnc pilot)
I’ll try and and upload the firmware to my 3d printer and run some more tests on tuesday. I’ll let you know
1 Like
Yeah I see, the oscilloscope is necessary to run a test like yours right?
Tried a cartesian compile to see f anything would move but same story, no luck 
The scope allows me to see (literally) the output signal of each individual Pin and do some more deep analysis, like timings, frequencies…etc. Things that with a simple Led or multimeter you just can’t measure.
For this purpose a logic analyzer would work too.
1 Like
So after some more testing on my other Arduino Mega (the one that powered my 3D printer) I got some astonishing and quite confusing results. 
When I upload µCNC to the Arduino Mega board and then connect OpenCNCPilot nothing happens.
If I send manual commands through a terminal window the board replies correctly but then stalls if I send a G code command.
If I connect to the serial port with a usb to serial adapter (bypassing the onboard atmega16U2) chip. communications work flawlessly. The MCU is still stalling when I send a G code command. (side note: my other board that you saw in the picture with the scope is a broken board that lacks the atmega16U2 chip so I run it directly with a USB to serial cable).
If disable the DSS option I get step generation but only for the first command.
When I “wire” µCNC DOUT15 pin to the L led pin of the board I can see that µCNC is running because it’s blinking with a steady 1 second rate.
I went back to use the onboard and reduced the pulling rate of OpenPilot to 500ms and communications work.
Then I look at your print screen and I see that the communications are running (debug log).
So resuming…a lot of strange things going on this particular board. The performance seems very
inconsistent between boards that should behave the same way.
The other funny thing is that in the emulator things run fine. Usually it’s the other way around.
The other problem on AVR is the debugging. Not an easy task as in ARM. I’m going to try to break my firmware into parts and test it.
EDIT: I think I’ve found the issue (at least the one related to the step generation). I started by turning off features that uses interrupts (specially those that use timers) and I hit a nerve at 1st strike. If I disable PWM0 the step generator works again and GCodes are executed.
I’m going to review the PWM configuration code and I’ll let you know later.
EDIT2: While I’m changing code on my side you can try this.
On your cnc_config.h file set TOOL_COUNT to 0
#ifndef TOOL_COUNT
#define TOOL_COUNT 0
#endif
On your boardmap_ramps14.h file comment the PWM0 definitions like this:
// Setup PWM
// #define PWM0_BIT 5 // assigns PWM0 pin
// #define PWM0_PORT H // assigns PWM0 pin
// #define PWM0_OCR C
// #define PWM0_TIMER 4
Recompile and upload and tell me how if it’s working
1 Like
I’ve patched master branch. You can also try that one. PWM is not messing up stepgen.
Tested on my arduino mega and it’s working.
The thing that I did not solve yet (If I’m able to) is the communication problem when it goes through the atmega16U2 chip. If your board does not complaint fine. If it does you can try to modify the OpenPilot status poll interval to something like 500ms. From 400ms and above works with USB.
EDIT: There is still an issue and I think I have a clue to what it is. For now just compile with TOOL_COUNT option set o 0. I seem to have found the issue. At least it’s working ok on my board. Master has been patched. My board is working ok.
1 Like
Ill be trying it tonight and will let you know!
1 Like