Abort job button & next move

[Pooky1306]

Tried safety features and new reset functions this evening and ran in a strange thing:

• while running job, pressed abort job button

  machine stops, alarm state triggered popup shows

• press option 1: reset and clear queue

  all ok

• Next I sent a jog move Z 10mm up, as if I was removing the broken tool or whatever from the part

  Go to Z+10 BUT I got X and Y move, like if the last line or last move was still in some sort of buffer

[ghost]

What did the Queue number indicator on the right above the dro show? If the queue was in LaserWeb's queue it will have a number there. Of the queue was already sent to the controller, its a different story (i'll need to investigate)

[cprezzi]

@Pooky1306 : Do you use Smoothie or Grbl? Which version?

[ghost]

I know he's on a smoothie (:

[ghost]

https://plus.google.com/collection/UAoPsB is his setup with one of my designed (Brian Bland built) Smoothiebrainz

On Dec 6, 2016 11:47 AM, "Claudio Prezzi" notifications@github.com wrote:

@Pooky1306 https://github.com/Pooky1306 : Do you use Smoothie or Grbl? Which version?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/issues/200#issuecomment-265106049, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr25aWIti3uEQnFxxwaCmOtMHOVj1oks5rFS8pgaJpZM4LEuDV .

[Pooky1306]

Yup ;) Found some clues:

Just tested again with a gcode files containing only X moves, then only Y then combined XY back and forth. The gcode must be more than the buffer size otherwise it works ok.

When abort occur, the DRO values displayed change to the last point but the machine stays in place. After reset the queue is cleared but when a move is sent, the machine goes back this last point because at this moment there's a difference between the physical position and the one displayed in DRO.

If not clear, example: Gcode: G0 X0 Y0 G0 X50 Y50 G0 X0 Y0 G0 X50 Y50 etc.. many times

Aborted during a X50 Y50 to X0 Y0 move machine stops at about X25 Y25 reset and clear > DRO now displays X50 Y50 (last pos in gcode) but the machine is still stopped at X25 Y25 Did a jog Z+10 machine goes from X25 Y25 Z0 to X50 Y50 Z10 . DRO and machine are sync.

[cprezzi]

Hm. This behaviour should not be possible as Smoothie executes all commands in the planner before stopping (after a hold command).

What exactly do you mean with "pressed abort job button"? Did you click the "Stop" Button on LaserWeb or a hardware button connected to you smoothieboard? Or something else?

[Pooky1306]

Yes all tests are done by pressing the Abort job button in LW.

I can do a video if it helps. I can reproduce the problem on each try

[Pooky1306]

Note that the change of DRO values occurs when the abort button is pressed, not after reset.

[Pooky1306]

Hmm I'm on a Pipo X9 win10

[cprezzi]

Ok, I was able to replicate this issue.

On "abort job" we send a reset command to smoothie to stop the machine immediately, which smoothie does. Then you get the alarm popup because smoothie sends an alert. After clearing the alert, we get the following warning (from smoothie) in the SysLog area: "WARNING: After HALT you should HOME as position is currently unknown". That's all expected.

But the reaction when jogging z after all this is not expected, and I cannot explain it. It looks to me like an issue of smoothie for the moment, but we have to investigate some more.

@openhardwarecoza : We should probably extract an example for this issue and ask Arthur and Jim. What do you think?

[ghost]

@arthurwolf @wolfmanjm

[cheton]

This is similar to a question that I asked two days ago (https://github.com/cheton/cnc/issues/94#issuecomment-264863350).

@wolfmanjm mentioned that it's necessary to home ($H) after unlocking ($X) from alarm mode. After homing, it should be able to work as expected.

[cprezzi]

I did expect that the machine has to be homed after a hold (like the waring sais), but it's still weird that the machine moves in x/y when it's jogged in z (if not homed).

This could be a security issue when somebody stopped his CNC because of a broken milling cutter and then needs to jog to safe z height before homing.

[wolfmanjm]

I do not think this is a smoothie issue. sending control X will clear the smoothie job queue and usually even leaves the position for where the actuators currently are.(it may need homing as an abrupt stop on some machines will cause it to lose steps or coast). If it moves in X or Y after this then I suspect there is a gcode in the comms queue on the host side which was not cleared. It is possible that if a gcode is sent after the control X that will be stuck in the USB buffer, but any gcode received by smoothie after control X will be rejected with a error:Alarm lock instead of an OK, the host MUST handle this as an immediate stop and clear its buffers and queues. I suspect LW does not currently handle it correctly? BTW I use control X all the time from a console and have never seen this issue. (Not to say it may be some odd edge case with LW and smoothie communication). (EDITED: in grbl mode it does not send !! it sends alarm lock, but if not in grbl mode it will send !!, it may be necessary for LW to handle both, unless LW requires smoothie to be in grbl mode)

[Pooky1306]

The strange thing during the test is the sudden change on the DRO (which are read from smoothie if I'm right ?)

Test method to produce the issue:

Gcode: G0 X0 Y0 G0 X50 Y50 G0 X0 Y0 G0 X50 Y50 etc.. many times Abort during a X50 Y50 to X0 Y0 move machine stops at about X25 Y25 > DRO values immediately change to X50 Y50 (last pos in gcode) but the machine is still stopped at X25 Y25 (unsync?) reset and clear Do a jog Z+10 machine goes from X25 Y25 Z0 to X50 Y50 Z10 . DRO and machine are sync.

[wolfmanjm]

how is it aborting? How is it reading the DRO? How is it resetting and clearing?

M114 for instance reads the last milestone which is the last received gcode which is different from the real time position. ? reads the current actuator position and uses FK to get the cartesian position. It looks like it is reading the last milestone instead of the actual position.

[wolfmanjm]

Also what version of smoothie are you running?

[wolfmanjm]

It definitely looks to me like LW is sending another gcode AFTER it sends the abort.

[wolfmanjm]

try this.. put your test gcode on sdcard. connect with a console. play /sd/testfile.g wait for the X50 X50 and send control X do a ? and see where it is do $X to clear the alarm do ? to see where it is (should be same as above) then do your Z move

if this works correctly then it is not a smoothie issue but a LW communication glitch. (FWIW this works for me with the current edge)

[cprezzi]

@wolfmanjm : Thank you for stepping in.

Here is what we do on a abort: port.write('!'); // send hold gcodeQueue.length = 0; // clear our the queye port.write("M5\n"); // make sure laser is off (-> eventually this is the problem?) port.write(String.fromCharCode(0x18)); // send ctrl-x

The following alarm triggers a popup that the user must clear (sends M999).

In parallel, there is an intervall that sends ? every 250ms. The position response reads WCO for the DRO.

I can check the exact smoothie version tomorrow in the office, but it is firmware-cnc w/o grbl mode.

[wolfmanjm]

don't send the hold.... that is what is causing the issue on smoothie, just send control X.

[wolfmanjm]

also do not send M5 that is not required and you cannot send anything anway after ! or control X Control X is abort and it turns everything off.

[wolfmanjm]

and you should use $X to clear the alarm

[cprezzi]

Ok thanks. That all is old behaviour which I am reworking now. I will try your tipps tomorrow.

[cprezzi]

What is grbl mode for?

[wolfmanjm]

As smoothie serves 3d printers which use a nonconforming form of gcode, there is a grbl mode to make responses and gcode more NIST gcode compliant, so it tries to respond with the same responses as grbl does. You need to be using a smoothie firmware that is a cnc build and will be in grbl mode by default (for recent versions).

[cprezzi]

Ah ok, then I probably have grbl mode on by default.

[cprezzi]

I have reduced the abort behaviour to just send ctrl-x and later on, when the user clears the alarm, we send $X. @Pooky1306 could you please test again?

[Pooky1306]

@cprezzi just tested, same method, same results. edit: just did a git pull, nothing else needed ?

[wolfmanjm]

There could be an issue if the user pauses (which issues !) then sends control X. try just doing the abort (control X) only without the pause. See if that is different. If it is I may be able to flush something in the USB driver after a pause.

[cheton]

Hi @wolfmanjm,

Below are my steps to abort a G-code program against a hold. Do you see any problems here?

1. Clear out the queue
2. Send ~ to resume a hold state
3. Send ctrl-x to abort
4. Unlock Alarm ($X)
5. Retract Z to a clearance height
6. Home ($H)

[wolfmanjm]

@cheton skip step 2 it is not needed and may cause issues. As will aborting while paused possibly.

[cprezzi]

@Pooky1306 Yes, git pull should be enough. I will change the behaviour again a bit and get back to test.

[ghost]

@Pooky1306 have you tested after the git pull?

[Pooky1306]

I'll do it this evening and post results.

[cojarbi]

I have tested this as follows:

press abort press option one > machine stops immediately selected option 1 Press a macro i have to send my machine to X0 Y0

Result was as expected.

[Pooky1306]

Mmh still the same on my machine but there's an error somewhere in my config. I don't know if it is critical as I use it as that since half a month and just noticed it today by looking on the console.

: Build version: edge-dcf0252, Build date: Nov 27 2016 14:18:23, MCU: LPC1769, System Clock: 120MHz : CNC Build : error:Invalid statement

Edit: looks like issue201

@cojarbi when you hit abort, DRO displayed in LW stops at the actual position ? (you need a gcode with long linear moves and longer than buffer size to see that) Edit: mine https://drive.google.com/open?id=0B3rOLUu_uwqNdUNuMjZ3aGlHbDg What if instead sending X0 Y0 you jog at Z+10 ?

Other point: by mistake I clicked outside the reset pop-up box and it disappeared with the machine still in halt state. Refresh the page bring it back.

[cojarbi]

It does stop inmediatly for me but did not try on a longer movement.

Will try later tonight

⁣Ariel Yahni​

On Dec 13, 2016, 08:40, at 08:40, MaxFavre notifications@github.com wrote:

Mmh still the same on my machine but there's an error somewhere in my config. I don't know if it is critical as I use it as that since half a month.

: Build version: edge-dcf0252, Build date: Nov 27 2016 14:18:23, MCU: LPC1769, System Clock: 120MHz : CNC Build : error:Invalid statement

@cojarbi when you hit abort, DRO displayed in LW stops at the actual position ? (you need a gcode with long linear move to see that) What if instead sending X0 Y0 you jog at Z+10 ?

Other point: by mistake I clicked outside the reset pop-up box and it disappeared with the machine still in halt state. Refresh the page bring it back.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LaserWeb/LaserWeb3/issues/200#issuecomment-266740729

[cojarbi]

Ok so i tested you gcode and indeed the behavior is strange.

Gcode does stops inmediatly even if the queved count is not empty ( if empty it also stops ) but:

If the movement is forward the live preview will show the status stop as the origin on the line and my macro G0 X0 Y0 will not work. Pressing other movement buttons will send the head back to the "origin" in a fast movement

If the movement is backwards ( returning from the corner ) the live preview will show the status stop at the end, my macro will work but very slowly

from there i my G0 X0 Y0 macro is not executed but if i press any movement

[cprezzi]

@cojarbi : Be aware that this issue is only on smoothie, not Grbl!