Maslow Home Maslow Community Garden Newsletter

Strange cut behavior

#1

Disclaimer: I’m using development WebControl (branch that should be updated to 9.27 with some minor communication changes in the web socket.).

System was calibrated and fully functional. I changed my rpi SD card because I want my buttons to work. I transferred the .json file from the webcontrol release version I was using yesterday on a very similar gcode file, got the system set and loaded. The config came up, the home position was the same. After moving to an uncut board section, the system was “homed” and then when play was pressed, it went back to literal home and cut while the software board showed the gcode cutout in the correct location, the actual red crosshairs in software were moving in another spot on the board and the actual cut was about 2 feet from where it should have been.

image
image3795×2038 489 KB

here’s a screen shot I took while it was going. I figured I might as well see what happens. no errors were shown. when it finished, I pressed the home button and it went back to where I had originally set it.

What would cause the system to use absolute home rather than the “zeroed home?” The Home location even says Y is 447.42… is it out of bounds?

#2

This is on your modified WebControl? Does your modification allow you to set home via a button?

#3

yes, the modified webcontrol. Home is set via the pendant. Home shows up in the screen shot above (Home = -77, 447.42, which is where the green crosshair is. Once play is pressed, it goes down and to the right, where the red crosshair is, to do the actual cut while the black crosshair traces the blue imaged cut lines. When complete, it goes to center home. Then when Home is pressed with the pendant, it moves back to the green crosshair. Only when the Play command is given do things go sideways.

this is the message from the controller when play is pressed:

line could not be moved:
G00 X130.351280 Y136.802840
Sending: G00 X130.351280 Y136.802840

#4

Does your define home function call actions.defineHome() or did you create your own? If you created your own, then you probably missed setting self.data.gcodeShift. WebControl was built upon ground control’s functions and evolved over time and we end up tracking the same value in different variables.

#5

if(‘defineHome’ in resultlist):
print (‘new home set’)
app.nonVisibleWidgets.actions.processAction({“data”:{“command”:“defineHome”,“arg”:"",“arg1”:""}})

I was editing the post above with this error message when you responded:

line could not be moved:
G00 X130.351280 Y136.802840
Sending: G00 X130.351280 Y136.802840

There is a problem when processing the gcode file, but it doesn’t tell why, perhaps printing everything in the gcodefile.py moveline() function will show show something. it could be a gcode file issue.

I did add a couple flags in the gcodefile.py but looking at them again, they don’t do anything, so I took them out.

I tried another file:

G00 Z5.000000
G00 X129.150000 Y118.737510
G01 Z-10.000000 F800.0(Penetrate)
G01 X218.050000 Y118.737510 Z-10.000000 F650.000000
G00 Z5.000000

message:

Sending: M3
Sending: G90
Sending: G21 G21
Sending: G00 Z5.000000
line could not be moved:
G00 X129.150000 Y118.737510
Sending: G00 X129.150000 Y118.737510
stopping run

(I stopped it here when it started moving a long distance)

This is all from the webcontrol webpage. no pendant connected. button service not running.

#6

Does it work when you define home using the define home button on the web client? I’m curious to see if something broke, perhaps due to units mismatch (i.e., the shift is in mm but the units are in inches or something).

#7

if I upload a file to webcontrol and then move it to another webcontrol installation, it should not matter?

All testing is now from the web page. Behavior is the same.

#8

can you post the gcode, please.

#9

which one? I’ve tried 4 different ones and they worked before.

#10

any file

#11

Call app.data.actions.processAction and see if that changes things.

#12

one note on this. The way we currently do ‘set home’ and re-write the g-code on the fly is not right. We really should modify the firmware to support g54 (and related gcodes) rather than doing this in GC/WC

1 Like
#13

@madgrizzle I’ll change the action calls.

@dlang Setting home in webcontrol works the way we are doing it. I’m not advocating changing that, I’d just like to return to basic functionality that was lost.

#14

I don’t think the action call will do any good based upon our discussion on private message thread regarding using python 3.7. hopefully there’s a solution that works on both, or maybe we can detect which version is being used and act accordingly.

#15

but based on “proper call” etiquette, I changed the 12 references in main.py to be correct. Easy find/replace… only took 20 seconds.

1 Like
#16

Okay, so the issue is a deprecated regular expression string format from python 3.5 to 3.7.

(line 454 in /Files/gcodefiles.py)

fmtX = “%0%.%sf” % len(eNtnX)

The actual hangup is taking the X and Y value from the gcode line and formatting them for the correct number of decimal places. The saved home position is then used to shift the line position, but with the error it fails. The original number is sent to the controller from webcontrol, so the cut is offset from the real home position rather than the user saved home position. This bug does not affect any of the release software because this is a development version and I’m using a newer python version than gets distributed with WebControl. If any of you are wizards with regular expression string parsing in python, have a look.

1 Like