I just upgraded grbl from 0.9j to 1.1 and started using the new 1.1

I just upgraded grbl from 0.9j to 1.1 and started using the new 1.1 jpadie workspace. I’ve used 0.9 for a few years with good luck. The machine seemed to misbehave in a few ways. A few times my g10 p1 l20 commands to set the WCS did not survive a restart after hitting the e-stop. Also, it took off in a seemingly random direction a few times after a job finished, causing me to hit the e-stop. And at the point I gave up last night, it seemed to be responding to commands in mm, but displaying inches, even though Chillipeppr’s numbers ended in ‘mm’. It looked like Chillipeppr was sending $13=1 over and over. Anyone else?

Inches are a known issue. Entirely my fault for trying to normalise between the display, the reporting and the gcode. In trying to make things more user friendly I borked inches.
Tried to fix it back in September but ended up breaking something else. It is just a case of sitting down and finding a few hours to look at the code again.

I can’t explain the other issues you report save to say that when you upgrade from 0.9 to 1.1 you will have to redo all your settings. There is a settings page in the workspace.

So is the 1.1 workspace not usable for mm units currently? Is there an issue queue for your fork somewhere? I think the WCS issue is probably a grbl issue, but wondered if anyone else had seen it. I’m not sure if many people use that G10 command.

My workspace should be usable for both sets of units. But for inches you should explicitly send G commands and settings through the serial console to ensure that everything is talking the same units.

mm should ordinarily work.

@Justin_Adie Seems like I shut down and reconnected and reloaded the workspace and it was still doing it, like it was stuck in an odd state. I was trying to use mm. I’ll try it again tonight.

Have a look in the settings screen for what the reporting is.
And check the serial console to make sure that the grbl controller is explicitly told and acknowledging what G mode it is in.

Jogging however uses a different interface. But that should not effect general milling.

I had mainly given up on using ChiliPeppr for things else than visualization due to my reliance on the jpadie workspace. I rarely CNC mill anymore but I use the Universal Gcode Sender (java based) when I do. I had switched to 1.1 grbl myself some time ago to start more trouble than I had before. Grbl is not the best in Chilipeppr. I would suggest a separate development environment if it does not have one.

Delighted if anyone else wants to fix the code! Just issue a pull request.

@NathanielStenzel Ugh… There’s no way I’m going back to UGS… I’ll fix the bugs myself if I have to.

@Justin_Adie Jogging seems to work fine.

It works in mm mode. Odd things happen in inches.

The core use case that is not catered for (and which gives problems) seems to be jogging etc in inches prior to loading gcode.

I just connected and started with everything turned off. X, Y, and Z are all reporting 0.000. When I jog, it’s jogging in MM. The coordinates do not change and continue to read 0.000.

Clearing my eeprom and re-entering my settings seems to have fixed the zero issue.

do yourself a favor and get mach 4 software and buy the PMDX-424 motion control board so that you don’t have to connect to the json server! all your problems will go away because you’ll never have to connect to a server again! just load the program you made with fusion 360 into the mach 4 software, and it runs perfect every single time!

I think I heard of a pi zero or pi zero w removing the problems as well. I am not exactly sure of how those setups work though.

@dominick_luciano Money solves everything!

Hi Everyone,
seems I have discovered this issue for myself. First noticed $13=1 being constantly sent to console along with $$. I found it stopped doing this when I clicked on the green com bar a few times. However, I then saw that the graphic was barely moving when I jogged. Everything in the real world was working fine, just the virtual router bit was wrong. Discovering what $13 was I tried sending $13=0. Bingo it stopped sending previous stuff and virtual bit was moving properly.

I might be interested in having a go at the code if I can work up my grasp of how this CP functions.