New PNP machine:

421 views
Skip to first unread message

The Maker Team

unread,
Dec 17, 2020, 10:06:51 AM12/17/20
to OpenPnP
I have built a new PNP machine and it is using a  SKR V1.3 32Bit CPU Mother Board  with  marlin bugfix-2.0.x firmware.

I am pretty sure everything is setup correctly because I am able to move all axis's in another g-code program without any issues. However, when I setup OpenPnP with the Gcode Driver it seems to connect to the board just fine but none of the JOG controls are working for me. I know it works because I can go to the console in OpenPnp and send  g-code commands and it does indeed move correctly. Any help would be appreciated.

- Paul

bert shivaan

unread,
Dec 17, 2020, 12:08:03 PM12/17/20
to OpenPnP
Paul, check that you have the step distance slider set up above the default of .01mm

This catches me all the time, seems like it is not moving.

--
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/6c9933be-2e61-43e9-992e-baf78416e478n%40googlegroups.com.

The Maker Team

unread,
Dec 17, 2020, 12:25:15 PM12/17/20
to OpenPnP
That was the first thing I checked and it is not the problem. Thanks for the reply.

bert shivaan

unread,
Dec 17, 2020, 12:33:26 PM12/17/20
to OpenPnP
What does the log show if you set it to trace.
Should be able to see the command sent when you press the button. Then hopefully you see the response from the controller when the move is done.

The Maker Team

unread,
Dec 17, 2020, 12:35:57 PM12/17/20
to OpenPnP
I will give that a check and get back to you soon

The Maker Team

unread,
Dec 17, 2020, 1:19:50 PM12/17/20
to OpenPnP
I am not getting any errors as far as I can see but nothing is moving when I jog it. Again when I go to the console and manually enter g-code it is moving.
Here is the trace log I got when trying to move around - 2020-12-17 13:14:09.432 ReferenceMachine DEBUG: setEnabled(true)
2020-12-17 13:14:12.354 ReferenceMachine DEBUG: homing machine
2020-12-17 13:14:12.356 AbstractMotionPlanner DEBUG: Reported location changes current location from (x:200.000000, y:0.000000, ReferenceControllerAxis:0.000000) to (x:0.000000, y:0.000000, ReferenceControllerAxis:0.000000)
2020-12-17 13:14:12.357 ReferenceHead DEBUG: H1.home()
2020-12-17 13:14:12.357 ReferenceNozzle DEBUG: ReferenceNozzle.home()
2020-12-17 13:14:12.357 ReferenceNozzle DEBUG: ContactProbeNozzle.home()
2020-12-17 13:14:12.358 Scripting TRACE: Scripting.on Machine.AfterHoming
2020-12-17 13:14:12.360 ReferenceMachine INFO: setHomed(true)
2020-12-17 13:14:16.672 AbstractHeadMountable DEBUG: ReferenceNozzle.moveTo((0.000000, -100.000000, 0.000000, 0.000000 mm), 1.0)
2020-12-17 13:14:16.673 ReferenceNozzle TRACE: ReferenceNozzle.transformToHeadLocation((0.000000, -100.000000, 0.000000, 0.000000 mm), ...)
2020-12-17 13:14:20.227 AbstractHeadMountable DEBUG: ReferenceNozzle.moveTo((100.000000, -100.000000, 0.000000, 0.000000 mm), 1.0)
2020-12-17 13:14:20.229 ReferenceNozzle TRACE: ReferenceNozzle.transformToHeadLocation((100.000000, -100.000000, 0.000000, 0.000000 mm), ...)
2020-12-17 13:14:22.148 AbstractHeadMountable DEBUG: ReferenceNozzle.moveTo((0.000000, -100.000000, 0.000000, 0.000000 mm), 1.0)
2020-12-17 13:14:22.149 ReferenceNozzle TRACE: ReferenceNozzle.transformToHeadLocation((0.000000, -100.000000, 0.000000, 0.000000 mm), ...)
2020-12-17 13:14:24.095 AbstractHeadMountable DEBUG: ReferenceNozzle.moveTo((-100.000000, -100.000000, 0.000000, 0.000000 mm), 1.0)
2020-12-17 13:14:24.096 ReferenceNozzle TRACE: ReferenceNozzle.transformToHeadLocation((-100.000000, -100.000000, 0.000000, 0.000000 mm), ...)
2020-12-17 13:14:26.875 AbstractHeadMountable DEBUG: ReferenceNozzle.moveTo((-100.000000, 0.000000, 0.000000, 0.000000 mm), 1.0)
2020-12-17 13:14:26.876 ReferenceNozzle TRACE: ReferenceNozzle.transformToHeadLocation((-100.000000, 0.000000, 0.000000, 0.000000 mm), ...)


ma...@makr.zone

unread,
Dec 17, 2020, 2:05:21 PM12/17/20
to ope...@googlegroups.com

Hi

Is this the newest OpenPnP Version i.e. with the axes visible in the Machine Setup tree?

If yes: have you used the Issues & Solutions system to try and find the issue?

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

_Mark

The Maker Team

unread,
Dec 18, 2020, 2:01:00 AM12/18/20
to OpenPnP
Thanks for the tip. I did look into the Issues and solutions and I applied all the fixes however, still no go from the jog buttons but it did show signs of movement when I hit the home button it move the x, y, and z about 1mm to 2mm and quit. The log is now showing communication from the controller card now.
But it still does not seem to move the axis's very strange.

Here is the log file.

2020-12-18 01:52:10.428 ReferenceMachine DEBUG: setEnabled(true)
2020-12-18 01:52:13.435 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(G21 ; Set millimeters mode, 5000)...
2020-12-18 01:52:13.436 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(G90 ; Set absolute positioning mode, 5000)...
2020-12-18 01:52:13.437 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G21
2020-12-18 01:52:13.437 GcodeDriver$ReaderThread TRACE: [serial://COM4] << ok
2020-12-18 01:52:13.438 GcodeDriver TRACE: [serial://COM4] confirmed G21
2020-12-18 01:52:13.439 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G90
2020-12-18 01:52:13.440 GcodeDriver$ReaderThread TRACE: [serial://COM4] << ok
2020-12-18 01:52:20.056 ReferenceMachine DEBUG: homing machine
2020-12-18 01:52:20.057 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(G28 ; Home all axes, -1)...
2020-12-18 01:52:20.057 GcodeDriver TRACE: [serial://COM4] confirmed G90
2020-12-18 01:52:20.057 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M400 ; Wait for moves to complete before returning, -1)...
2020-12-18 01:52:20.058 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M114 ; get position, -1)...
2020-12-18 01:52:20.058 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G28
2020-12-18 01:52:22.058 GcodeDriver$ReaderThread TRACE: [serial://COM4] << echo:busy: processing
2020-12-18 01:52:23.326 GcodeDriver$ReaderThread TRACE: [serial://COM4] << X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
2020-12-18 01:52:23.326 GcodeDriver TRACE: Position report: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
2020-12-18 01:52:23.327 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (x:0.000000, y:0.000000)
2020-12-18 01:52:23.327 GcodeDriver$ReaderThread TRACE: [serial://COM4] << ok
2020-12-18 01:52:23.327 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2020-12-18 01:52:23.327 GcodeDriver TRACE: [serial://COM4] confirmed G28
2020-12-18 01:52:23.328 AbstractMotionPlanner DEBUG: Reported location changes current location from (x:1700.010000, y:2200.000000) to (x:0.000000, y:0.000000)
2020-12-18 01:52:23.328 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M400
2020-12-18 01:52:23.328 ReferenceHead DEBUG: H1.home()
2020-12-18 01:52:23.328 ReferenceNozzle DEBUG: N1.home()
2020-12-18 01:52:23.328 GcodeDriver$ReaderThread TRACE: [serial://COM4] << ok
2020-12-18 01:52:23.329 Scripting TRACE: Scripting.on Machine.AfterHoming
2020-12-18 01:52:23.329 GcodeDriver TRACE: [serial://COM4] confirmed M400
2020-12-18 01:52:23.330 ReferenceMachine INFO: setHomed(true)
2020-12-18 01:52:23.330 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M114
2020-12-18 01:52:23.332 GcodeDriver$ReaderThread TRACE: [serial://COM4] << X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
2020-12-18 01:52:23.332 GcodeDriver TRACE: Position report: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
2020-12-18 01:52:23.333 GcodeDriver$ReaderThread TRACE: [serial://COM4] << ok
2020-12-18 01:52:28.265 AbstractHeadMountable DEBUG: N1.moveTo((100.000000, 0.000000, 0.000000, 0.000000 mm), 1.0)
2020-12-18 01:52:28.266 ReferenceNozzle TRACE: N1.transformToHeadLocation((100.000000, 0.000000, 0.000000, 0.000000 mm), ...)
2020-12-18 01:52:28.269 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M204 S666.67 G1 X100.0000  F15491.93 ; move to target, 5000)...
2020-12-18 01:52:28.269 GcodeDriver TRACE: [serial://COM4] confirmed M114
2020-12-18 01:52:28.270 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M204S666.67G1X100F15491.93
2020-12-18 01:52:28.271 GcodeDriver$ReaderThread TRACE: [serial://COM4] << ok
2020-12-18 01:52:30.161 AbstractHeadMountable DEBUG: N1.moveTo((100.000000, 100.000000, 0.000000, 0.000000 mm), 1.0)
2020-12-18 01:52:30.162 ReferenceNozzle TRACE: N1.transformToHeadLocation((100.000000, 100.000000, 0.000000, 0.000000 mm), ...)
2020-12-18 01:52:30.164 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M204 S666.67 G1  Y100.0000 F15491.93 ; move to target, 5000)...
2020-12-18 01:52:30.164 GcodeDriver TRACE: [serial://COM4] confirmed M204S666.67G1X100F15491.93
2020-12-18 01:52:30.165 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M204S666.67G1Y100F15491.93
2020-12-18 01:52:30.165 GcodeDriver$ReaderThread TRACE: [serial://COM4] << ok

It looks like the commands are being sent because the controller is responding with ok as you can see.
Is there something I am missing here because this thing is working with a g-code sender but not with openpnp.

ma...@makr.zone

unread,
Dec 18, 2020, 2:28:35 AM12/18/20
to ope...@googlegroups.com

Could you send the machine.xml?

The Maker Team

unread,
Dec 18, 2020, 9:43:34 AM12/18/20
to OpenPnP
Here it is -
machine.xml

ma...@makr.zone

unread,
Dec 18, 2020, 10:20:31 AM12/18/20
to ope...@googlegroups.com

Hi Maker Team

It seems you don't have a Z-axis defined!

Normally one is provided in the default configuration or migrated from a previous version's machine.xml.

So I guess you must not yet have defined it in the machine.xml after you switched from the NullDriver to the GcodeDriver, then migrated to the new version. Or maybe you deleted it somehow, afterwards?

Btw. in the new version you get a clear Warning now:

So start by defining the Z axis:

https://github.com/openpnp/openpnp/wiki/Machine-Axes

Then assign it to your nozzle:

Assigning Axes

https://github.com/openpnp/openpnp/wiki/Mapping-Axes

_Mark

The Maker Team

unread,
Dec 18, 2020, 11:25:01 AM12/18/20
to OpenPnP
Yes, it was there and I did remove it. I was having trouble understanding what it was asking for. It wanted to have me configure nozzles and other stuff. 
I just wanted to see some life to it before I get into all that. I want it to simple move my x and y axis to make sure I am able to talk to my controller before I configure everything else. 

Is that possible? or do I have to configure a z with a nozzle and everything else? 

Being unfamiliar with any PNP software I am kind of lost with the whole configuration.
This OpenPNP was not an upgrade. It was installed from the latest version. I made sure of that by uninstalling it and re-installing the on from https://openpnp.org/downloads/. I got the 64bit version for windows.

As frustration builds here I am considering other options but before I do I want to make sure I have at least given OpenPNP a fair shot.

Should I consider installing Smoothieware on my controller?
Maybe my marlin configuration is not right in some way.

 I have looked at the OpenPNP version of Marlin but it is for a Teensy controller and I am not sure what changes have been made to Marlin to support that controller and if my will even work under that configuration.
My controller is a BigTree Tech SVR v1.3 and it does support Soothieware firmware.

I am not new to building machines. I have built several CNC machines and several 3D printers.

I am just new to all this PNP stuff. When it starts asking for RegEX this and RegEX that I am lost lol. Things like this -
2020-12-18 11:16:25.761 GcodeDriver WARNING: Axis ReferenceControllerAxis letter Z missing in POSITION_REPORT_REGEX groups.
2020-12-18 11:16:25.762 GcodeDriver WARNING: Position report cannot be processed when motion might still be pending. Missing Machine Coordination on Actuators?

Seems very cryptic to me. POSITION_REPORT_REGEX groups I will be honest here. I have no idea what it is talking about or what it is looking for or what I can do to fix it. This is what I got after I added the Z axis.

- Paul
 

ma...@makr.zone

unread,
Dec 18, 2020, 3:06:01 PM12/18/20
to ope...@googlegroups.com

Hi Maker Team

Hang in there. You need tons of frustration tolerance to get a DIY Pick & Place going. But you'll also learn tons of stuff and it feels great, afterwards!

First you need to realize that all you're configuring is (for now) in the machine.xml file here:

https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located

So if you feel you've reached a dead-end or everything so far was just a trial, you can exit OpenPnP, backup the current  machine.xml (in case you reconsider) and delete it.

When you restart OpenPnP it will create a new machine.xml for you. The default machine will have created the axes for a single nozzle machine. But everything else (driver/cameras) is just simulated.

From this you can start setting up your machine.

General note: Whenever you think you've reached a good intermediate state, make sure to exit OpenPnP or use File / Safe Configuration and then make a new backup of the machine.xml. You can always go back to this by restoring the file later. Just make sure to have exited OpenPnP before doing that (OpenPnP overwrites the file when it exits).

Unfortunately, the Wiki is currently in transition.

  • There is the old way to setup a machine in the regular table of contents (right side bar). Most of this still aplies but when it comes to axes, and drivers and having to hack the machine.xml manually, it is no longer accurate.
  • There is the new way to setup the machine in the Advanced Motion Control section. At the end of each of these new pages, you have the toc of the new/changed features. These replace the similar old features. The Wiki will be re-integrated in the next weeks/months.

A few first steps to get you going:

You can delete the default driver (NullDriver) and create a proper GcodeAsyncDriver.

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#for-new-drivers

> My controller is a BigTree Tech SVR v1.3 and it does support Soothieware firmware.

If you can install my firmware, this would give you the best automatic setup support. However, I don't know if the BigTree Tech SVR v1.3 is fully hardware compatible with the Smoothieboard. Maybe somebody here on the list knows?

https://makr.zone/smoothieware-new-firmware-for-pnp/500/

With the standard Marlin firmware you can still create a good single nozzle machine (it is only for the multi.nozzle machines that stock Marlin is suboptimal). Also, stock Marlin has less automatic setup support in OpenPnP.

Once you have figured this out, you can use the Issues & Solutions system to guide you through the steps. Be sure to use the [i] button to lead you to the proper Wiki pages. 

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

It can even propose the Gcode for the most complicated commands and regular expressions.

Then you can replace the simulated cameras with OpenPnPCaptureCameras. Etc.

https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration%3A-General-Camera-Setup

I hope this helps as a starter.

_Mark

The Maker Team

unread,
Dec 18, 2020, 9:37:12 PM12/18/20
to OpenPnP

Mark I want to thank you for all the help you have provided. While I am no where near done with this thing. I can now happily tell you it is now at least moving all the axis's. Of course the problem was indeed something silly as I thought it would be but here is what I found out.
I did a single Y axis move of 100 using the Jog controls and while looking at the Trace of the g-code I noticed it was sending this command - M204 S666.67 G1 Y100 F15491.93. So, it was attempting to set the feed rate and spindle speed followed by the in this case the y axis move of 100 followed by the feedrate of the actual move.
This M204 S666.67 was being set along with every move.
So, of course Marlin would have no idea what it is talking about here.
After playing around a bit with the settings I found the issue. Under the Driver in the Gcode settings it has a drop down with six items in it. Mine was set on Constant acceleration. Once it was changed to ToolPathFeedrate it started working because the G-code that was being output changed to G1 Y100.0000 which is correct in my case.

ma...@makr.zone

unread,
Dec 19, 2020, 4:26:05 AM12/19/20
to ope...@googlegroups.com

Hi Maker Team

> I can now happily tell you it is now at least moving all the axis's.

Cool.

> After playing around a bit with the settings I found the issue. Under the Driver in the Gcode settings it has a drop down with six items in it. Mine was set on Constant acceleration. Once it was changed to ToolPathFeedrate it started working because the G-code that was being output changed to G1 Y100.0000 which is correct in my case.

You should read about these settings and what they mean. They are the central choice how OpenPnP's new Advanced Motion Control works.
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#gcodedriver-new-settings

If you set it to ToolpathFeedRate, you have if effectively dumbed down to nothing. :-(

One of the reasons why you want better Motion Control is for better speed factors. OpenPnP will control the motion so that for instance a 50% speed factor results in exactly double the motion time. But this only works, if acceleration is controlled in addition to feed-rate.
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors

Tell me if that description is too complicated. It is always hard for me to document something understandably, after having spent so much time thinking about it. ;-)

>This M204 S666.67 was being set along with every move.
> So, of course Marlin would have no idea what it is talking about here.

The M204 sets the allowed acceleration. Marlin should support it:
https://marlinfw.org/docs/gcode/M204.html

Btw. the reason the feed-fate numbers are so odd (like F15491.93 in your case) is because OpenPnP predicts how fast the machine will move (peak) for the given length of move. Setting the limit to the predicted value will make sure the speed control is always mostly effective, even if the controller is able to apply optimizations that deviate from the prediction.

_Mark

Javier Hdez.

unread,
Dec 19, 2020, 6:08:44 AM12/19/20
to OpenPnP
Very nice workshop.

Also I've a SKR but I have not had time to configure it, I hope to do it soon. You will tell us if it goes well with Marlin

Best regards

The Maker Team

unread,
Dec 19, 2020, 10:10:21 AM12/19/20
to OpenPnP
I understand what it is trying to do and I am not sure why the latest version of Marlin is not supporting it. I also think your description of what it is doing it just fine and very understandable. When a g-code is sent with those items it simply will not move at all. At this point in the game I simply do not care about any advanced movement techniques
outline here. I simply wanted to see some life in my machine so I can move forward with getting the rest of the machine configured to start pick and place testing. 

If the result is unsatisfactory I figure I can tweak later to fix it. I am using TB6600 external drivers on a small machine using belt drive with some pretty powerful Nema 17 motors (overkill for this setup to be sure) and I have adjusted the firmware to get the federate and acceleration spot on for this configuration. It is moving at breakneck speed with little to no jerk with nearly no backlash at all. Certainly acceptable for my plans to use this machine to pick and place boards. It does not need to be perfect it just needs to work. Even slowly would be fine for me. I can work out accuracy later when everything is functional and once I get a handle on how this whole thing works. I just need a starting point to get going and that is where I am at now. You have a done a wonderful job and I appreciate all the help, thank you. I am sure I will run into some other hiccups along the way but for now I can at least get to work on the rest of the machine. I will also play around with some of the other settings and let you know if they work on Marlin for me.

EuclideanAxisLimits
ConstantAcceleration
ModeratedConstantAcceleration
SimpleSCurve
Simulated3rdOrderControl
Full3rdOrderControl

- Paul

ma...@makr.zone

unread,
Dec 19, 2020, 11:20:45 AM12/19/20
to ope...@googlegroups.com

Hi Maker Team

I have three controller types attached here, but no Marlin controller. Could you help me with testing and improving this?

First thing to try:

Maybe Marlin does not support both a M and G command on the same line. It should according to the standard (NIST RS274NGC Interpreter - Version 3, Section 3.3.5 Item Repeats), but you know how it is.

Try adding a newline in front of the G1 so the M204 Sxxx  is on a separate line, like so (but with your command):


To test, you need to set it back to ConstantAcceleration in Driver Settings:

Second thing to try:

Having it on the same line is a bit faster. Maybe it does support it on the same line, but it requires a spaces between M and G words. Again requiring this is not standards conforming, but it seems likely as e.g. Duet had the same problem (already fixed there).

So put it back together on one line:

Switch off the Compress Gcode option off:

Test again.

Once you can confirm one of these two work, I will build that into the Issues & Solutions system, so the next user will have the solution ready.

If somebody in/near Switzerland has an unused Marlin laying around (partly damaged drivers don't matter), you could help by sending it to me. ;-)

Thanks for helping!

_Mark

The Maker Team

unread,
Dec 19, 2020, 11:36:31 AM12/19/20
to OpenPnP
I would be more than happy to help you out with this. I will do all of that and get back to you with my results to make it better for others. 

- Paul

The Maker Team

unread,
Dec 19, 2020, 1:08:41 PM12/19/20
to OpenPnP
ok as a control I put it back into constant acceleration and tested it before doing anything to make sure it was not working. It was not working. I then changed the g-code to make it so it was not on a single line and retested it. Wahoo works way better than before really moved great. I then checked to see if white space in the code made any difference and it does not so seem to be the case as far as I can tell. it looks like the two line solution is the ticket here. Not standard but seems to work really well. Thanks again for all your help. Kick ass support my friend.

- Paul

Reply all
Reply to author
Forward
0 new messages