Not sure where to post,

CAD & CAM Tool Chain ChiliPeppr
1

Not sure where to post, so I have dual posted here and the google group.

Good Day all !!!

I am nearing the end of a full rebuild of my machine (Shapeoko II). This means a enclosure for the electronics, full rewiring throughout the machine (it was always a slop with prayers that it would hold through the job), and the addition of homing switches. In the process, I figured I would also get myself caught up with GRBL 1.1 (on a GRBL Shield). Chilipeppr has been my goto interface of choice ever since it was made public.

Once I started powering everything up, I have been troubleshooting all the little things that come up. I have resolved most of them, but I am still not in the position to start running jobs. I have a couple of things which are causing some real stress as I can not find any real answers. Read that to mean, yes, I have been searching and working like crazy to fix as much by myself as possible. But I have hit a wall here and it seems that here is where I need to start asking for some guidance.

I have seen the posts about using the Jpadie workspace. So, I have started to try to use that. This made it possible to see some feedback as to location n such. The problem, it seems, starts when I home. I have my X and Y inverted for the homing cycle so that I land at my lower left hand corner. Homing seems to work well. But this is where the oddness starts. I will get an incorrect read in my movement. I am set to work in mm. If I ask the machine to move 10mm, it seems to move 10mm (The spindle is off, but it looks like a visual 10mm). The readout however will display that I have moved a fraction of a mm. I saw a post where someone had a similar issue. John asked the person to click the in/mm button. When I try this, it is a similar situation in movement. It seems to be a proper movement, but incorrect reading. Initially I thought I might have found the issue as I had $10 set to 3 (my GRBL .9 setting). I set this to 1, but it is still not working.

Another symptom which might be something new, but I am unfamiliar with (this build has taken far too long (over a year) do to work, family, and life in general). Where I was quite up to speed on everything before I started, I have not been in the loop for a while, so all advancements have passed me by. I am looking for documentation, videos, anything, but I am not seeing this…
After homing, I see a string that is unfamiliar. The string contains a feed rate. I am thinking that this is the new jogging mode in action, but the speed is silly slow. I figured it would take the seek feed rate but this doesn’t seem to be the case. Unfortunately I am at work so I can’t give an example of the string it’s placing. Prior to homing the machine moves about similar to what I was used to prior to the upgrade.

Having read that there seems to be some things not quite right with the combo of Chilipeppr and GRBL 1.1 in general, I (reluctantly) have started trying a couple of other softwares. Interestingly I have the same problems there as well, which tells me that either 1. I have something configured incorrectly (which is quite probable). or 2. There really is some oddness in 1.1 which needs to be addressed and I need to be patient, or go back to .9 (which I am having some issues with as well).

So, I will leave this here. I am just not sure which direction I need to head. Thanks for any help you can provide. I can get any screen type info you need as soon as I get home from work in a couple of hours.

Mike

2

An update. Did some testing tonight. A movement of 100 mm (tested with a metal ruler with both mm and 1/2 mm lines) shows a reading of 3.937 in the DRO.
The machine was zeroed prior to this move.
The line was $J=G91X+100.000F2000 which looks correct.

So CP sent the line, the machine moved accordingly, and correctly, but it displays incorrectly.

3

this is an inches vs mm issue. to standardise the interface enter G20/G21 (whatever you want) in the serial box and send it. that should set the reporting and display to the same units.

this is one of the edge cases that I have been trying to thinks of a neat way to solve without reverting to the unit translation method of display.

4

I think the workspace may have had a dodgy commit a week ago as another user was reporting that the units were reversed and that feedhold wasn’t working. these were all errors right from the start of the workspace.
i’ve refreshed the github repo and the right version is now being served.
please let me know if your errors are persisting.

5

I finally got a chance to get back down here and test. Something is screwy. Chiipeppr is issuing a $13=1 command? I don’t think that it should ever force a different setting without some sort of notification. If I sent the machine off 100mm I am still safe, but if unknown to me you set it to inches, I am going to crash my machine.
Here’s more oddness. It’s sending these commands about once every 2 seconds. There’s no way to function as it’s constantly trying to update my setting $13.
“$13=1
$$”

6

Oh dear. So you’re seeing this too.

The widget absolutely does force the board to report in inches/mm so that display, handling and reporting are all harmonised.

It should only ever do this when the G20/21 modal state is not the same as the reporting. So if the board is set to report in inches and you have a modal state of G21 then it will send $13=0 if the setting is not already $13=0; and then follow up with a setting refresh to ensure that the value has persisted.

The fact that it is doing this the wrong way around for you and that the setting is being repeatedly forced is very odd.

This workspace was never intended to be used in production. It’s always been flagged as experimental since Christmas when Luca and I created it. Now that John has elevated it to official I think I will have to roll back the harmonisation code and go to the rather clunky mechanism that was originally used. I will do that this morning.