POSITION_REPORT_REGEX broken in latest OpenPnP version
Ravi Ganesh
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
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
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
mark maker
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:
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
--
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/bb186737-1691-44e2-a3ff-0d1a81c14f34n%40googlegroups.com.
surab...@gmail.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:
- Change of serial port Flow Control recommended: Set RtsCts on serial port:- really not required!!
- MOVE_TO_COMPLETE_COMMAND: G4 P0;
- HOME_COMMAND: $H;
- 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:
- 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.
- 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
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000c01d7de30%240c122070%2424366150%24%40gmail.com.
surab...@gmail.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
> 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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000001d7de43%24460c5f30%24d2251d90%24%40gmail.com.
surab...@gmail.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.
surab...@gmail.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
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000201d7df03%243a489450%24aed9bcf0%24%40gmail.com.
surab...@gmail.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
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000001d7df14%24444e96a0%24ccebc3e0%24%40gmail.com.
mark maker
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4cd535f4-2c0d-c9ab-8a60-0fc404898889%40makr.zone.
surab...@gmail.com
Hi Mark,
Here is a video of GcodeAsync in action with grbl.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4cd535f4-2c0d-c9ab-8a60-0fc404898889%40makr.zone.
mark maker
> 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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000001d7dfdd%2421505c00%2463f11400%24%40gmail.com.
surab...@gmail.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….
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/880f303e-b81e-eb35-cdfd-b71dd6e0d557%40makr.zone.
surab...@gmail.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…. 😉
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ffe74f52-5318-3022-7174-e0eb4653537b%40makr.zone.
mark maker
> 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000801d7dfe1%24bc947300%2435bd5900%24%40gmail.com.
mark maker
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000d01d7dfe2%24c7c15c60%2457441520%24%40gmail.com.
surab...@gmail.com
Hi Mark,
You must have a relook into this arc stuff.
Meanwhile I will try for a video for a proof of concept.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2c2eb200-acf5-b281-d3c4-68b8a9512262%40makr.zone.
surab...@gmail.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2c2eb200-acf5-b281-d3c4-68b8a9512262%40makr.zone.
Sandra Carroll
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/001001d7e029%24dabf2580%24903d7080%24%40gmail.com.
mark maker
Hey Ravi,
please open a new topic/thread for the arc discussion.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000001d7e028%24b09e5880%2411db0980%24%40gmail.com.
surab...@gmail.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
mark maker
> Mark I have made a pull request for grbl.
Will respond in the PR:
> 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/000901d7e15e%248d67e250%24a837a6f0%24%40gmail.com.