POSITION_REPORT_REGEX broken in latest OpenPnP version

146 views
Skip to first unread message

Ravi Ganesh

unread,
Nov 20, 2021, 2:10:06 AM11/20/21
to OpenPnP

Hi I upgraded from OpenPnP Nov 2020 version to the latest version.

The following is the Gcode for POSITION_REPORT_REGEX

<WPos:(?<x>-?\d+\.\d+),(?<y>-?\d+\.\d+),(?<z>-?\d+\.\d+),(?<rotation>-?\d+\.\d+)>

And this worked fine and the current position of DRO in openPnP is in sync with the controllers position.

 

I upgraded to the latest openPnP version and POSITION_REPORT_REGEX seems to be broken.

This is the trace:

2021-11-20 12:10:31.126 GcodeDriver DEBUG: [serial://COM5] >> M114, 2000

2021-11-20 12:10:31.126 GcodeDriver$ReaderThread TRACE: [serial://COM5] << <WPos:0.000,0.000,0.000,0.000>

2021-11-20 12:10:31.126 GcodeDriver TRACE: Position report: <WPos:0.000,0.000,0.000,0.000>

2021-11-20 12:10:31.126 GcodeDriver WARNING: Axis x letter missing in POSITION_REPORT_REGEX groups.

2021-11-20 12:10:31.126 GcodeDriver WARNING: Axis y letter Y missing in POSITION_REPORT_REGEX groups.

2021-11-20 12:10:31.126 GcodeDriver WARNING: Axis z letter Z missing in POSITION_REPORT_REGEX groups.

2021-11-20 12:10:31.126 GcodeDriver WARNING: Axis rotation letter E missing in POSITION_REPORT_REGEX groups.

2021-11-20 12:10:31.126 GcodeDriver WARNING: Position report cannot be processed when motion might still be pending. Missing Machine Coordination on Actuators?

2021-11-20 12:10:31.126 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-20 12:10:31.126 GcodeDriver TRACE: [serial://COM5] confirmed M114

 

Is there a setting in OpenPnP to make the old position report work without explicitly expecting X Y  Z etc?

 

 

mark maker

unread,
Nov 20, 2021, 3:41:36 AM11/20/21
to ope...@googlegroups.com

It seems you have your axis letters not set up right. I cannot see how a recent upgrade could do that.

You need to set the axis letters on the axes according to the controller. I don't know which axes Grbl has.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/281efde3-2555-4544-9f1b-30c8a35f873an%40googlegroups.com.

Ravi Ganesh

unread,
Nov 20, 2021, 6:43:48 AM11/20/21
to OpenPnP

Mark,

This is how grbl reports position:

<WPos:0.000,0.000,0.000,0.000>

 And it is working fine in November 2020 build of openPnP. (yes a bit old)

 But the current version is not taking this format. I think it expects something like <WPos:X=0.000,Y=0.000,Z=0.000,C=0.000>


Ravi Ganesh

unread,
Nov 20, 2021, 7:31:34 AM11/20/21
to OpenPnP
 Mark
I changed the POSITION_REPORT_REGEX from  
<WPos:(?<x>-?\d+\.\d+),(?<y>-?\d+\.\d+),(?<z>-?\d+\.\d+),(?<rotation>-?\d+\.\d+)>

to
<WPos:(?<X>-?\d+\.\d+),(?<Y>-?\d+\.\d+),(?<Z>-?\d+\.\d+),(?<E>-?\d+\.\d+)>

and the warnings disappeared. 

But still the DRO in openPnP  does not get reset to the controllers coordinate and they are both out of sync.


This is my CONNECT_COMMAND
G21 ; Set millimeters mode
G90 ; Set absolute positioning mode
M114


and this the trace
2021-11-20 17:42:00.371 ReferenceMachine DEBUG: setEnabled(true)
2021-11-20 17:42:01.398 GcodeDriver$ReaderThread TRACE: [serial://COM5] << Grbl 1.1h ['$' for help]
2021-11-20 17:42:01.398 GcodeDriver DEBUG: [serial://COM5] >> G21 ; Set millimeters mode, 2000
2021-11-20 17:42:01.398 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok
2021-11-20 17:42:01.398 GcodeDriver TRACE: [serial://COM5] confirmed G21 
2021-11-20 17:42:01.398 GcodeDriver DEBUG: [serial://COM5] >> G90 ; Set absolute positioning mode, 2000
2021-11-20 17:42:01.398 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok
2021-11-20 17:42:01.398 GcodeDriver TRACE: [serial://COM5] confirmed G90 
2021-11-20 17:42:01.398 GcodeDriver DEBUG: [serial://COM5] >> M114, 2000
2021-11-20 17:42:01.457 GcodeDriver$ReaderThread TRACE: [serial://COM5] << <WPos:0.000,0.000,0.000,0.000>
2021-11-20 17:42:01.457 GcodeDriver TRACE: Position report: <WPos:0.000,0.000,0.000,0.000>
2021-11-20 17:42:01.457 GcodeDriver WARNING: Position report cannot be processed when motion might still be pending. Missing Machine Coordination on Actuators?
2021-11-20 17:42:01.457 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok
2021-11-20 17:42:01.457 GcodeDriver TRACE: [serial://COM5] confirmed M114


mark maker

unread,
Nov 20, 2021, 8:05:37 AM11/20/21
to ope...@googlegroups.com

Hi Ravi,

Please read and follow this carefully. I spent a lot of time and effort to write this. 🤓

You should be using Issues & Solutions, otherwise we will never get automatic Grbl setup going...

As Grbl is not yet recognized by I&S, set to "generic" here:

Connect Firmware

https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions#connect-milestone

Then you can let I&S guide you.

You need to assign Axis Letters first.

https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings

Does Grbl really have an E axis? I thought this was a CNC rather than 3D print controller? Can you change that in configuration to be designated as C? The 3D printing specific "extruder" stuff should really be avoided. If C is not possible, perhaps A is, as the second-best solution.

Once the correct axis letters are figured out and assigned to axes, I&S should be proposing the right POSITION_REPORT_REGEX for you. And all the other commands too (except for actuators).

CONNECT_COMMAND, HOME_COMMAND are not proposed, when already set, so you should delete these in the driver, to be sure to get fresh proposals. Check if correct for Grbl.

Where Grbl does not work with the "generic" proposition by OpenPnP Issues & Solutions, report it to me, so I will be able to automatically propose that in the solution, once Grbl is recognized.

> But still the DRO in openPnP  does not get reset to the controllers coordinate and they are both out of sync.

Automatic position updating does not work spontaneously (not possible with asynchronous operation). You need to enable Location Confirmation, if you want that, and this will be controlled by OpenPnP:

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#settings

_Mark
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

surab...@gmail.com

unread,
Nov 20, 2021, 12:00:00 PM11/20/21
to ope...@googlegroups.com

Hi Mark,

I started the configuration afresh and I am amazed at its guidance. I am happy to get grbl do the work I want with the settings I&S suggested except for a few:

  1. Change of serial port Flow Control recommended: Set RtsCts on serial port:- really not required!!
  2. MOVE_TO_COMPLETE_COMMAND: G4 P0;
  3. HOME_COMMAND: $H;
  4.  POSITION_REPORT_REGEX suggested. ^.*X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) .*C:(?<C>-?\d+\.\d+).*

 

Is there a possibility to make openPnP use it without the axis letters (for backward compatibility?)

A couple of queries:

  1. When is the SET_GLOBAL_OFFSET_COMMAND used? Right now I use G92 X0 .. right after my homing.  I would prefer to go by your suggestion.
  2. The only place I currently use POSITION_REPORT_REGEX is during disconnection. If for any reason I need to disconnect the hardware and reconnect without reopening OpenPnP, the controllers and OpenPnP coordinates are different and the fist jog crashes the nozzle most often. All I need it to reset OpenPnP coordinates to the controllers coordinates. Is there any other way to update this from a script that can be performed after connect?

 

And my answers to your questions:

>>Does Grbl really have an E axis?

This was added by Bob Beattie in 2014 for openPnP. My work is derived from this.

 

>> Can you change that in configuration to be designated as C:

It is inded C

>> Where Grbl does not work with the "generic" proposition by OpenPnP Issues & Solutions, report it to me, so I will be able to automatically propose that in the solution, once Grbl is recognized.

 

I think Grbl will be more easy to recognize than any of the other two firmwares 😉 Just four issues.

 

Ravi

 

 

mark maker

unread,
Nov 20, 2021, 12:11:47 PM11/20/21
to ope...@googlegroups.com

1. OK

2. OK

3. OK

4. It is possible, but I strongly  recommend changing the M114 command to report the letters as all the other controllers do:
    https://www.reprap.org/wiki/G-code#M114:_Get_Current_Position
    There is also an extra axis order sanity check in OpenPnP that would not be possible without the letters

Your Questions:

1. It is used after Visual homing to adjust the coordinate system. It is also used to perform rotation axes wrap-around at +/-360°. I don't see why your use of G92 after homing should not work too, in combination. In fact it is the same on Duet.

2. This should really be a task for homing.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

surab...@gmail.com

unread,
Nov 20, 2021, 2:17:38 PM11/20/21
to ope...@googlegroups.com

Mark,

Will do #4 as per your advice.

 

Regarding #2 (POSITION_REPORT_REGEX)

We don’t have limit switches. We visually jog to a reference (usually the first pick location) and then touch offset the nozzle and press home, which just sends as G92 command (and some custom code in grbl to set the machine coordinates and enable soft limits basically to prevent crash)

So your advise how to sync the controller and OpenPnp during that vulnerable phase will immensely help me prevent those crashes.

 

G92 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f}

Is a good choice??

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/F6naybpW9yY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2542b761-701a-d864-0019-ab8b16491161%40makr.zone.

mark maker

unread,
Nov 20, 2021, 3:42:33 PM11/20/21
to ope...@googlegroups.com

> We don’t have limit switches.

Just to be sure: Grbl can support limit-switches, right? You are just talking about your machine, right?

> We visually jog to a reference

In this case you best setup Visual Homing.

https://github.com/openpnp/openpnp/wiki/Visual-Homing

Jog (or with still unpowered motors manually move) the machine to the homing fiducial. Move the nozzle down to the table. Then press the homing button.

The HOME_COMMAND would then set X, Y to the known homing fiducial X, Y coordinates, and Z to the known table surface Z (and A to 0) coordinate using G92.

NOTE:  (as I said earlier) if you enable Location Confirmation, OpenPnP will sync itself with the coordinates after the homing.

Then Visual Homing takes over and refines that manual coordinate to a precision reference, again using G92 but only for X, Y.

G92 can be used in both commands, it is not a "push-pop stack" or something, it just overwrites the current coordinates with new ones.

_Mark

surab...@gmail.com

unread,
Nov 21, 2021, 1:51:11 AM11/21/21
to ope...@googlegroups.com

HI Mark,

I am blessed to have some assistants  who do the human visual homing as good and as quick as the machine visual homing, if not better. They would be dejected if the machine took over all their jobs. I am also happy with fine balance between complete robotics to complete manual work. If the big companies also follow this philosophy rather than look at profits alone the world would be happier place ???

 

Ok enough of philosophies.

Grbl does indeed support limit switches, but I personally am not using it. Even in our CNC mills we do dial homing. I.e set up a dial in the exposed part of the ball screw and jog for it. It gives an accuracy of 0.01mm that no limit switch can give I presume.

 

Location Confirmation: I selected the basic gcode driver. I will try with the async driver today. I am sure it would give me some delightful surprises with the advanced motion planning.

 

image001.png
image002.jpg
oledata.mso

surab...@gmail.com

unread,
Nov 21, 2021, 1:11:43 PM11/21/21
to ope...@googlegroups.com

Hi Mark,

Coming to this POSITION_REPORT_REGEX issue.

 

Rather than describing the problem which is laborious, I will point to some code fragment that you can readily inspect.

 

GcodeDriver.java

In function

processPositionReport(Line line)

 

        if (motionPending) {

            Logger.warn("Position report cannot be processed when motion might still be pending. Missing Machine Coordination on Actuators?",

                    position);

        }

        else {

            // Store the actual driver location. This is used to re-sync OpenPnP to the actual controller

            // location, when its axes might have moved/homed etc. behind its back.

            position.setToDriverCoordinates(this);

        }

 

 

1.           Looks like "position" is dummy

2.           "motionPending"  is not reset after a move in all paths. E.g during camera jog it is reset, but not when jogged with buttons...

 

 

Please have a look and let me know your comments.

 

 

 

mark maker

unread,
Nov 21, 2021, 1:57:33 PM11/21/21
to ope...@googlegroups.com
First of all:

I understand the need to be pragmatic, i.e. skip the end-switches. But then perhaps use a power cycle to home the machine. Unpower the machine, move the nozzle manually to the homing location, power on. The controller will reset to zero coordinates.

Then add G92 to your HOME_COMMAND (like I explained earlier) to set arbitrary (non-zero) homing X, Y etc.

But if still you want to sync OpenPnP, I can only repeat myself:

Automatic position updating does not work spontaneously (not possible with asynchronous operation). You need to enable Location Confirmation, if you want that, and this will be controlled by OpenPnP:

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#settings

Don't be afraid of the GcodeAsyncDriver.

Au contraire I urge you to test it, we need to confirm that Grbl is compliant, otherwise I cannot in good conscience add it to the list of officially supported firmwares. 😇

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

surab...@gmail.com

unread,
Nov 21, 2021, 3:13:42 PM11/21/21
to ope...@googlegroups.com

Mark,

I did some testing with a plain Arduino and I can confirm it works fine.

Attached is the long list of Traces in different combinations.

 

Here are some suggestions:

Assign Axis Letters as XYZC and save the user from typing.

Axis Name and Axis Letter to be Capitals.

 

 

The vacuum valve actuator AVAC has no ACTUATE_BOOLEAN_COMMAND assigned.  May be assigned tentatively like this: (True:M9) (False:M8)

 

HOME_COMMAND  $H; &  G92 X0 Y0 Z0 C0 (optionally)

 

MOVE_TO_COMPLETE_COMMAND G4 P0;

 

 

Axis is not assigned to a driver suggestion comes up only after closing and opening OpenPnp. New user can get stuckup here. Looks like a small glitch

Also milestone Kinematics gets completed after closing and opening..

 

 

 

Tomorrow I will do it on the machine.

 

 

The four traces are for single axis “button” jogging, camera jogging with flow control and location confirmation in all combinations.

 

 

 

 

2021-11-22 01:11:31.949 AbstractHeadMountable DEBUG: Top.moveTo((54.775000, 25.240000, 0.000000, 0.000000 mm), 1.0)

2021-11-22 01:11:31.949 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G1 X54.7750    F1000.00 ; move to target, 5000)...

2021-11-22 01:11:31.965 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G1 X54.7750    F1000.00 ; move to target

2021-11-22 01:11:31.965 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

 

2021-11-22 01:12:23.654 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)

2021-11-22 01:12:23.654 AbstractHeadMountable DEBUG: N.moveToSafeZ(1.0)

2021-11-22 01:12:23.654 AbstractHeadMountable DEBUG: Top.moveToSafeZ(1.0)

2021-11-22 01:12:23.654 AbstractHeadMountable DEBUG: Top.moveTo((84.430329, 24.861102, 0.000000, 0.000000 mm), 1.0)

2021-11-22 01:12:23.654 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G1 X84.4303 Y24.8611   F1000.00 ; move to target, 5000)...

2021-11-22 01:12:23.654 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G4 P0, 5000)...

2021-11-22 01:12:23.670 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G1 X84.4303 Y24.8611   F1000.00 ; move to target

2021-11-22 01:12:23.670 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:12:23.670 GcodeDriver TRACE: [serial://COM5] confirmed G1 X84.4303 Y24.8611   F1000.00 ; move to target

2021-11-22 01:12:23.670 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G4 P0

2021-11-22 01:12:24.545 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:12:24.545 GcodeDriver TRACE: [serial://COM5] confirmed G4 P0

2021-11-22 01:12:24.545 GcodeAsyncDriver TRACE: GcodeAsyncDriver confirmation complete.

2021-11-22 01:12:24.545 AbstractHeadMountable DEBUG: Top.moveTo((84.430329, 24.861102, 0.000000, 0.000000 mm), 1.0)

 

 

 

 

 

 

 

2021-11-22 01:09:41.803 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)

2021-11-22 01:09:41.803 AbstractHeadMountable DEBUG: N.moveToSafeZ(1.0)

2021-11-22 01:09:41.803 AbstractHeadMountable DEBUG: Top.moveToSafeZ(1.0)

2021-11-22 01:09:41.803 AbstractHeadMountable DEBUG: Top.moveTo((33.925361, 12.376834, 0.000000, 0.000000 mm), 1.0)

2021-11-22 01:09:41.803 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G1 X33.9254 Y12.3768   F1000.00 ; move to target, 5000)...

2021-11-22 01:09:41.819 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G4 P0, 5000)...

2021-11-22 01:09:41.819 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(M114 ; get position, -1)...

2021-11-22 01:09:41.819 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G1 X33.9254 Y12.3768   F1000.00 ; move to target

2021-11-22 01:09:41.819 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G4 P0

2021-11-22 01:09:41.819 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> M114 ; get position

2021-11-22 01:09:41.819 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:09:42.491 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:09:42.491 GcodeDriver$ReaderThread TRACE: [serial://COM5] << X:33.920 Y:12.379 Z:0.000 C:0.000

2021-11-22 01:09:42.491 GcodeDriver TRACE: Position report: X:33.920 Y:12.379 Z:0.000 C:0.000

2021-11-22 01:09:42.491 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:09:42.491 GcodeDriver TRACE: GcodeAsyncDriver got lastReportedLocation (X:33.920000, Y:12.379000, Z:0.000000, C:0.000000)

2021-11-22 01:09:42.491 GcodeAsyncDriver TRACE: GcodeAsyncDriver confirmation complete.

2021-11-22 01:09:42.491 AbstractMotionPlanner DEBUG: Reported location changes current location from (X:33.925361, Y:12.376834, Z:0.000000, C:0.000000) to (X:33.920000, Y:12.379000, Z:0.000000, C:0.000000)

2021-11-22 01:09:42.491 AbstractHeadMountable DEBUG: Top.moveTo((33.925361, 12.376834, 0.000000, 0.000000 mm), 1.0)

2021-11-22 01:09:42.507 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G1 X33.9254 Y12.3768   F1000.00 ; move to target, 5000)...

2021-11-22 01:09:42.507 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G4 P0, 5000)...

2021-11-22 01:09:42.507 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(M114 ; get position, -1)...

2021-11-22 01:09:42.507 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G1 X33.9254 Y12.3768   F1000.00 ; move to target

2021-11-22 01:09:42.507 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G4 P0

2021-11-22 01:09:42.507 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> M114 ; get position

2021-11-22 01:09:42.507 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:09:42.507 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:09:42.507 GcodeDriver$ReaderThread TRACE: [serial://COM5] << X:33.920 Y:12.379 Z:0.000 C:0.000

2021-11-22 01:09:42.507 GcodeDriver TRACE: Position report: X:33.920 Y:12.379 Z:0.000 C:0.000

2021-11-22 01:09:42.507 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:09:42.522 GcodeDriver TRACE: GcodeAsyncDriver got lastReportedLocation (X:33.920000, Y:12.379000, Z:0.000000, C:0.000000)

2021-11-22 01:09:42.522 GcodeAsyncDriver TRACE: GcodeAsyncDriver confirmation complete.

2021-11-22 01:09:42.522 AbstractMotionPlanner DEBUG: Reported location changes current location from (X:33.925361, Y:12.376834, Z:0.000000, C:0.000000) to (X:33.920000, Y:12.379000, Z:0.000000, C:0.000000)

 

 

 

2021-11-22 01:18:59.132 ReferenceHead DEBUG: H1.moveToSafeZ(1.0)

2021-11-22 01:18:59.132 AbstractHeadMountable DEBUG: N.moveToSafeZ(1.0)

2021-11-22 01:18:59.132 AbstractHeadMountable DEBUG: Top.moveToSafeZ(1.0)

2021-11-22 01:18:59.132 AbstractHeadMountable DEBUG: Top.moveTo((141.889534, 7.032228, 0.000000, 0.000000 mm), 1.0)

2021-11-22 01:18:59.132 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G1 X141.8895 Y7.0322   F1000.00 ; move to target, 5000)...

2021-11-22 01:18:59.132 GcodeDriver TRACE: [serial://COM5] confirmed M114 ; get position

2021-11-22 01:18:59.132 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G4 P0, 5000)...

2021-11-22 01:18:59.132 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(M114 ; get position, -1)...

2021-11-22 01:18:59.132 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G1 X141.8895 Y7.0322   F1000.00 ; move to target

2021-11-22 01:18:59.147 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:18:59.147 GcodeDriver TRACE: [serial://COM5] confirmed G1 X141.8895 Y7.0322   F1000.00 ; move to target

2021-11-22 01:18:59.147 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G4 P0

2021-11-22 01:18:59.882 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:18:59.897 GcodeDriver TRACE: [serial://COM5] confirmed G4 P0

2021-11-22 01:18:59.897 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> M114 ; get position

2021-11-22 01:18:59.897 GcodeDriver$ReaderThread TRACE: [serial://COM5] << X:141.893 Y:7.041 Z:0.000 C:0.000

2021-11-22 01:18:59.897 GcodeDriver TRACE: Position report: X:141.893 Y:7.041 Z:0.000 C:0.000

2021-11-22 01:18:59.897 GcodeDriver TRACE: GcodeAsyncDriver got lastReportedLocation (X:141.893000, Y:7.041000, Z:0.000000, C:0.000000)

2021-11-22 01:18:59.897 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:18:59.897 GcodeAsyncDriver TRACE: GcodeAsyncDriver confirmation complete.

2021-11-22 01:18:59.897 AbstractMotionPlanner DEBUG: Reported location changes current location from (X:141.889534, Y:7.032228, Z:0.000000, C:0.000000) to (X:141.893000, Y:7.041000, Z:0.000000, C:0.000000)

2021-11-22 01:18:59.897 AbstractHeadMountable DEBUG: Top.moveTo((141.889534, 7.032228, 0.000000, 0.000000 mm), 1.0)

2021-11-22 01:18:59.897 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G1 X141.8895 Y7.0322   F1000.00 ; move to target, 5000)...

2021-11-22 01:18:59.897 GcodeDriver TRACE: [serial://COM5] confirmed M114 ; get position

2021-11-22 01:18:59.897 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G4 P0, 5000)...

2021-11-22 01:18:59.897 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(M114 ; get position, -1)...

2021-11-22 01:18:59.913 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G1 X141.8895 Y7.0322   F1000.00 ; move to target

2021-11-22 01:18:59.913 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:18:59.913 GcodeDriver TRACE: [serial://COM5] confirmed G1 X141.8895 Y7.0322   F1000.00 ; move to target

2021-11-22 01:18:59.913 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G4 P0

2021-11-22 01:18:59.913 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:18:59.913 GcodeDriver TRACE: [serial://COM5] confirmed G4 P0

2021-11-22 01:18:59.913 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> M114 ; get position

2021-11-22 01:18:59.960 GcodeDriver$ReaderThread TRACE: [serial://COM5] << X:141.893 Y:7.041 Z:0.000 C:0.000

2021-11-22 01:18:59.960 GcodeDriver TRACE: Position report: X:141.893 Y:7.041 Z:0.000 C:0.000

2021-11-22 01:18:59.960 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok

2021-11-22 01:18:59.960 GcodeDriver TRACE: GcodeAsyncDriver got lastReportedLocation (X:141.893000, Y:7.041000, Z:0.000000, C:0.000000)

2021-11-22 01:18:59.960 GcodeAsyncDriver TRACE: GcodeAsyncDriver confirmation complete.

2021-11-22 01:18:59.960 AbstractMotionPlanner DEBUG: Reported location changes current location from (X:141.889534, Y:7.032228, Z:0.000000, C:0.000000) to (X:141.893000, Y:7.041000, Z:0.000000, C:0.000000)

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of mark maker
Sent: Monday, November 22, 2021 12:27 AM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] POSITION_REPORT_REGEX broken in latest OpenPnP version

 

First of all:

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/F6naybpW9yY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bb35ea40-adf4-d2b0-8362-7bc0c3dde5bd%40makr.zone.

mark maker

unread,
Nov 22, 2021, 3:31:40 AM11/22/21
to ope...@googlegroups.com

Hi Ravi,

> I did some testing with a plain Arduino and I can confirm it works fine.

Very good, thanks!

> The vacuum valve actuator AVAC has no ACTUATE_BOOLEAN_COMMAND assigned.  May be assigned tentatively like this: (True:M9) (False:M8)

Actuator commands are not yet covered by I&S (for none of the controllers) but I will keep this in mind.

> HOME_COMMAND  $H; &  G92 X0 Y0 Z0 C0 (optionally)

Does Grbl $H not reset to all zero implicitly?

Note, when I said yesterday that Location Conformation will help you to sync the machine initially, I was wrong.

The first Location Conformation sync happens after Home, but you need it right after Connect, so you can start jogging, before the Home. I will look into supporting that.

What I said about the unpowered machine is right, through, AFAIK other users use that method too. Perhaps a valid workaround for you, until this is fixed.

> Axis is not assigned to a driver suggestion comes up only after closing and opening OpenPnp. New user can get stuckup here. Looks like a small glitch

This should not happen when you use Issues & Solutions throughout, i.e. when you let I&S replace the NullDriver with a GcodeDriver, then the axes are all properly assigned. Likewise, when you use the Nozzle Solution to create more axes:

https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions#welcome-milestone

And finally when you use I&S in the Advanced Milestone to replace the GcodeDriver with the GcodeAsyncDriver. 

https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions#advanced-milestone

I assume you deleted the GcodeDriver and created a GcodeAsyncDriver manually?

Yes, then the axis driver assignments are lost. If I'm mistaken there, please report.

> Also milestone Kinematics gets completed after closing and opening..

Could you elaborate? The milestone is a simple enum, stored on the Solutions object. I cannot imagine how it could get "magically" completed...

_Mark

mark maker

unread,
Nov 22, 2021, 10:32:38 AM11/22/21
to ope...@googlegroups.com

Another thing:

You said:

> Change of serial port Flow Control recommended: Set RtsCts on serial port:- really not required!!

OK, but how does Grbl do serial flow control then? This is very important, especially with asynchronous operation!

Is this valid for your branch?

https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl#streaming-a-g-code-program-to-grbl

So it would be XON/XOFF.

_Mark

surab...@gmail.com

unread,
Nov 22, 2021, 3:11:33 PM11/22/21
to ope...@googlegroups.com

Hi Mark,

Here is a video of GcodeAsync in action with grbl.

https://user-images.githubusercontent.com/26599790/142923520-d34e4017-32c8-4632-aa72-8c807e849486.mp4

 

I was expecting some arc motions like in this drawing. Maybe I am missing some settings or not yet implemented.

 

 

Regarding you questions:

Grbl as far as I understand remembers the workoffset. So the next G90 X0 Y0 Z0 after home would move to the workpiece zero. Very useful in resuming CNC milling jobs after power outages.

 

Location confirmation: Yes I would be very happy. I just started playing with openPnP code. It would be least disruptive if ENABLE_COMMAND does variable substitution and send it down to the driver. Please I will toy with that and give a pull request.

 

Glitches: I started from the default null driver and the simulated machine. It is really amazing how fast I am able to get it to work with the real machine by following the I&S. I will try a few more times and report the exact experience.

 

BR

Ravi

image001.jpg

mark maker

unread,
Nov 22, 2021, 3:22:25 PM11/22/21
to ope...@googlegroups.com

> I was expecting some arc motions like in this drawing. Maybe I am missing some settings or not yet implemented.

No, unfortunately that is not possible as a general case, certainly not with 8bit Arduino, and - as it turned out to my own surprise - not even with the very performant Duet 3, due to limited USB serial bandwidth. See here:

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending

I guess it would have to be implemented on the controller, as a native 3rd order control implementation.

_Mark

surab...@gmail.com

unread,
Nov 22, 2021, 3:44:32 PM11/22/21
to ope...@googlegroups.com

Mark,

Grbl based machines being basic machines, I would suggest using the simple send response.

 

I also find that currently not more that 3 gcode commands are sent asynchronously before a wait command is sent. That is why with only “location Confirmation” I was able to run without buffer over flow errors.

 

Unless you are planning to send a lot of short move commands this should not be an issue. As I requested earlier, I would wish for implementation of arc motions before rapid moves in horizontal planes like the CNC machines do….

surab...@gmail.com

unread,
Nov 22, 2021, 3:52:00 PM11/22/21
to ope...@googlegroups.com

Hi Mark,

Grbl supports  arcs in the vertical planes. So it is doable. The more the head room the user can give between the safe zone and horizontal rapid motion plane, the more fluid the motion will be…. 😉

image001.jpg

mark maker

unread,
Nov 22, 2021, 4:20:08 PM11/22/21
to ope...@googlegroups.com

> Grbl based machines being basic machines, I would suggest using the simple send response.

OK, I will do that (like TinyG).

Note, you can still use the GcodeAsyncDriver, and it will still be more optimal, because it can use the time between two commands to plan the next:

GcodeDriver:

  • Plan
  • Send Command
  • Wait for Response
  • Plan
  • Send Command
  • ...

GcodeAsyncDriver:

  • Plan
  • Send Command
  • Plan
  • Wait for Response
  • Send Command
  • ...

> I would wish for implementation of arc motions before rapid moves in horizontal planes like the CNC machines do….

Don't understand what you mean.

mark maker

unread,
Nov 22, 2021, 4:25:08 PM11/22/21
to ope...@googlegroups.com

Yeah, but AFAIK G-code arcs are only supported in the X-Z or Y-Z plane, but moves are in arbitrary X-Y diagonals.

Believe me I have spent weeks/months investigating this.

_Mark

surab...@gmail.com

unread,
Nov 23, 2021, 12:12:26 AM11/23/21
to ope...@googlegroups.com

Hi Mark,

You must have a relook into this arc stuff.

Meanwhile I will try for a video for a proof of concept.

image001.jpg

surab...@gmail.com

unread,
Nov 23, 2021, 12:20:47 AM11/23/21
to ope...@googlegroups.com

Mark,

Pardon me if my earlier mail was missing some etiquette. Because English is not my native language (Tamil is)

Cheers,

Ravi

 

 

From: surab...@gmail.com <surab...@gmail.com>
Sent: Tuesday, November 23, 2021 10:42 AM
To: 'ope...@googlegroups.com' <ope...@googlegroups.com>
Subject: RE: [OpenPnP] POSITION_REPORT_REGEX broken in latest OpenPnP version

 

Hi Mark,

You must have a relook into this arc stuff.

Meanwhile I will try for a video for a proof of concept.

 

 

 

image001.jpg

Sandra Carroll

unread,
Nov 23, 2021, 8:43:17 PM11/23/21
to ope...@googlegroups.com

Hi Ravi

Sidebar, and a quick thank you as  I never knew what Tamil Language was until I looked it up because of your comment.

 

Sandra

image001.jpg

mark maker

unread,
Nov 24, 2021, 3:34:52 AM11/24/21
to ope...@googlegroups.com

Hey Ravi,

please open a new topic/thread for the arc discussion.

_Mark

Message has been deleted

surab...@gmail.com

unread,
Nov 24, 2021, 1:11:34 PM11/24/21
to ope...@googlegroups.com

Thankyou Sandra. There are 18 vibrant languages here. English is the link language as far as I believe.

 

Mark I have made a pull request for grbl. I have also tested it on a two PCB’s these two days.

Driver: GcodeAsyncDriver with Conformation Flow control only on.

Firmware: The same firmware sent in the pull request.

OpenPnP: developer version.

 

 

Ball rallied back to your court.

 

Attached video of machine in action

grblOpenPnP 2.mp4

mark maker

unread,
Nov 25, 2021, 3:00:33 AM11/25/21
to ope...@googlegroups.com

> Mark I have made a pull request for grbl.

> Ball rallied back to your court.

Yeah, but you will still test the Issues & Solutions Grbl integration, right? Perhaps backup your machine.xml and start with a fresh one, to see whether I&S does it all right?

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages