A little help with daisy chaining controllers

[Gino Magarotto]

Hi everybody. Can somebody please give me a hand with using a sub driver to relay commands to a second machine controller? I'm using GRBL to control the X and Y axes, and so far everything is working without issue. My plan is to make the vacuum heads fully self contained, and for this, I want to use a second controller to move the Z and rotation axes, activate the pumps and check the vacuum status of the nozzles on the head.  Any tips on how to link two controllers?

[Jason von Nieda]

Hi Gino,

See https://github.com/openpnp/openpnp/wiki/GcodeDriver#sub-drivers

And https://github.com/openpnp/openpnp/wiki/GcodeDriver%3A-Example-Configurations#sub-driver-example

Jason

On Sat, Nov 17, 2018 at 5:47 PM Gino Magarotto <otto...@gmail.com> wrote:

Hi everybody. Can somebody please give me a hand with using a sub driver to relay commands to a second machine controller? I'm using GRBL to control the X and Y axes, and so far everything is working without issue. My plan is to make the vacuum heads fully self contained, and for this, I want to use a second controller to move the Z and rotation axes, activate the pumps and check the vacuum status of the nozzles on the head.  Any tips on how to link two controllers?

--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2cb89a9e-1c30-45e6-8151-7495eb6518a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gino Magarotto]

Thanks Jason.

I'm not familiar with running OpenPnP with a Smoothieboard. If I understood correctly, the example uses the dedicated serial port on the LPC micro to relay the messages to the second controller, so the example can't be applied to GRBL controllers (with a single serial port Arduino) right away. Does the default Smoothieboard firmware already supports the message relaying? I'm thinking that maybe I can chain the GRBL controllers and feeder banks via I2C instead.

[bert shivaan]

Hi Gino, I may be wrong here, but I don't think the motion control passes any commands to the sub controls. What I think is the "main driver" and "sub driver" all live in oPNP. all your boards get their own serial port from the computer.

Maybe I am not correct, but this is my understanding.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7bda68b-78c4-419a-a8de-a878ebd77e0f%40googlegroups.com.

[bert shivaan]

Forgot to mention, GRBL seems to not be a favorite here. So there are only a few folks using it as far as I can tell. That is not to say you won't get help because you WILL!! I too am running GRBL on a mega. I hacked it a bit to add 24 custom M codes to control my head. They turn 24 air valves on and off.

I am not an arduino person really, but could not pass it up as a cheap solution. The mega only cost me $10USD at the local Micro center.

[Gino Magarotto]

Getting motion control for cheap is my main goal too. Getting a Smoothieboard becomes too expensive for me after paying for shipping and import taxes, that's why I went with GRBL.

I think I get you. The main Gcode driver transmits some commands to the serial port it has defined, and whether or not the motion controller on that port does something, the sub driver will pass the same commands, minus those that were not defined by the user in the sub driver, to the second machine controller. If that's the case, it does allow for some fantastic modulatity.

Many thanks for the reply!

[Marek T.]

Gino create Driver and Subdriver in Openpnp.

Put in Driver/PICK_COMMAND sample code M105 and in SubDriver/PICK_COMMAND sample code M106.

When need to execute PICK_COMMAND: M105 will be sent to serial#1, M106 ro serial#2.

If you declare only M105 in above sample - only serial#1 will be feeded with M105.

If you declare only M106 in above sample - only serial#2 will be feeded with M106.

Are you outside the EU? It's made in France and no taxes then, however agree the Smoothie is not the cheapest one...

[Gino Magarotto]

I think I get it. Let me get my controllers wired up and ready and I'll see if I can accomplish what I have in mind with this info.

Yup, I'm outside the EU, and due to my unreliable postal service I need to use DHL or Fedex if I want to get the board on a reasonable time frame. That would sadly put the Smoothie close to $300 USD for me, costlier than my 3 axis table and cameras setup.

[Gino Magarotto]

Ok, I can communicate with two GRBL controllers at the same time, but I'm still having trouble figuring how to do some things.

First, a description of my system: I'm using controller#1 to move my X and dual Y motors only. And controller#2 to take care of Z, two independent nozzle rotation motors and two pumps.

Is there a way to send Z jog commands to controller#2? I thought of removing the Z and rotation stuff from MOVE_TO_COMMAND of controller#1 and add them to MOVE_TO_COMMAND of controller#2, but the command only gets sent to controller#1. Should I handle everything connected to controller#2 as a head mounted actuator?

[Jason von Nieda]

Hi Gino,

The command should get sent to every controller (sub-driver) that has a command set. Make sure you set the command for the Default HeadMountable and it should go to both. If not, please set logging to TRACE and send a log.

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a2783ece-4630-4f48-a2fe-3534f02b185f%40googlegroups.com.

[Gino Magarotto]

Thanks for the reply.

I have set the same MOVE_TO_COMMAND for both the driver and sub-driver but only controller#1 is being addressed. Both controllers connect just fine when I start the machine, as per the log.

I took a look at the machine,xml file and the sub-driver appears to not have any axis mapping, unlike the sub-driver example on the wiki. Could this be the issue?

I'm attaching both files.

[Jason von Nieda]

Ah yea, the axis mapping defaults to nil on sub drivers. Just move z and rotation to the sub driver.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1fe28ca2-df3e-404a-950f-a675339ea2ca%40googlegroups.com.

[Gino Magarotto]

After editing the xmI fiel get the error "element 'axis' does not have a match in class org.openpnp.machine.reference.driver.GcodeDriver" when starting OpenPnp. What I'm I missing?

[Jason von Nieda]

Look closer at the main driver. You need the wrapping element. Axes, I think.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dd68fcd5-e9ac-4426-8d84-f35ae94801f0%40googlegroups.com.

[Gino Magarotto]

Jason, I'm sorry to bother you with this, but I can't find a way to make it work. The sub driver section should be like this, right?

         <sub-drivers class="java.util.ArrayList">
            <gcode-driver communications="serial" connection-keep-alive="true" units="Millimeters" max-feed-rate="1000" backlash-offset-x="-1.0" backlash-offset-y="-1.0" non-squareness-factor="0.0" backlash-feed-rate-factor="0.1" timeout-milliseconds="5000" connect-wait-time-milliseconds="3000" visual-homing-enabled="true" name="subDriver">
               <serial line-ending-type="LF" port-name="COM5" baud="115200" flow-control="Off" data-bits="Eight" stop-bits="One" parity="None" set-dtr="false" set-rts="false" name="SerialPortCommunications"/>
               <tcp line-ending-type="LF" ip-address="127.0.0.1" port="23" name="TcpCommunications"/>
               <homing-fiducial-location units="Millimeters" x="0.0" y="0.0" z="0.0" rotation="0.0"/>
               <command type="COMMAND_CONFIRM_REGEX">
                  <text><![CDATA[^ok.*]]></text>
               </command>
               <command type="MOVE_TO_COMMAND">
                  <text><![CDATA[G0 {Z:Z%.4f} {Rotation:E%.4f} F{FeedRate:%.0f} ; Send standard Gcode move]]></text>
                  <text><![CDATA[G4 P0 ; Wait for moves to complete before returning]]></text>
               </command>
               <command type="CONNECT_COMMAND">
                  <text><![CDATA[G21 ; Set millimeters mode]]></text>
                  <text><![CDATA[G90 ; Set absolute positioning mode]]></text>
               </command>
               <sub-drivers class="java.util.ArrayList"/>
               <axes class="java.util.ArrayList"/>
                  <axis name="z" type="Z" home-coordinate="0.0">
                     <head-mountable-ids class="java.util.HashSet">
                        <string>*</string>
                     </head-mountable-ids>
                  </axis>
                  <axis name="rotation" type="Rotation" home-coordinate="0.0">
                     <head-mountable-ids class="java.util.HashSet">
                        <string>*</string>
                     </head-mountable-ids>
                  </axis>
               </axes>
            </gcode-driver>
         </sub-drivers>

[bert shivaan]

Gino are you using standard GRBL or the one from oPNP? I ask because I am pretty sure standard does not support the C axis. In any event I see your rotation is still being called "E".

I assume this is not the issue you have right not, but just looking ahead for you on that.

Sorry I am no help for the current issue. :(

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ae7e4312-ae2d-4803-90e3-d061e6c47083%40googlegroups.com.

[Jason von Nieda]

Hi Gino,

That looks good to me. If you are still having problems, please post your full machine.xml, a description of what's wrong, and a log (with TRACE) enabled showing the issue.

Also, note what Bert mentioned. It looks like you are sending Z and E, but if you are using Grbl there is no E axis. With modifications there will be a C axis, and by default there is only X, Y, Z.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ae7e4312-ae2d-4803-90e3-d061e6c47083%40googlegroups.com.

[Gino Magarotto]

Thanks for the heads up. I'm using standard GRBL, and, as you say I will have to solve the axis designation issues someway. I'll make the info public once I get to it.

[Gino Magarotto]

Hi Jason, The issue I'm having is that I get and error prompt saying "the element 'axis' does not have a match in class org.openpnp.machine.reference.driver.GcodeDriver" when trying to launch OpenPnP after editing the machine.xml file. I cannot post a log because I can't get the program to run, but here's my current xml file.

[bert shivaan]

The version of GRBL in the openpnp github works wonderful and already has "C" worked out.

I started with that and made my needed modifications from there.

I am not sure the newer version really has anything to offer for a pick and place machine. There is no value in the laser mode or better planner with better look ahead. We don't need coordinated moves like a cutting machine does.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/34676acb-74f1-46f9-b791-2b9bbac880aa%40googlegroups.com.

[Gino Magarotto]

That's true, I'll take a look at the modified GRBL source to see what I can learn.

My machine supports 2 nozzles in a seesaw configuration, so my plan was to use a GRBL board just for the head, with Z controlling the up/down motion, and X/Y for nozzle rotation. I thought of sending Z, C1 and C2 Gcode moves to the sub-driver and making some tweaks to the GRBL command parser to "link" C1 and C2 to X and Y motor drivers.

[Gino Magarotto]

It seems that changing the axis designators in GRBL is really straightforward. I just had to replace X/Y/Z for any unused character in the gcode.c file (where the letter switch statement is). GRBL compiled without issue, and I now can send commands like this: G0 Z-10 C45 D0, where C and D are two nozzle rotation motors. I could even install a second head and another GRBL to easily get a four nozzle pnp.

[Jason von Nieda]

Hi Gino,

On line 347 you have <axes class="java.util.ArrayList"/> but it needs to be <axes class="java.util.ArrayList">. Note the / is removed from the end. The way you have it now ends the element, making it an empty list.

So, just remove that / from line 347 and you are good to go.

In addition, there is no need to change axis names in Grbl. OpenPnP doesn't care what the axes are named. Just change the Gcode you send from within OpenPnP in the GcodeDriver settings.

The only reason people use a Grbl that supports C is that it *adds* a C axis, making it a four axis controller instead of three. The names don't matter, it's the addition of a lot of code that makes it four axes that matters.

Subdrivers make that pointless. You can just keep adding stock 3 axis Grbls until you have enough axes. OpenPnP doesn't care of 10 of them are called "X" :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/34676acb-74f1-46f9-b791-2b9bbac880aa%40googlegroups.com.

[Gino Magarotto]

Many thanks for taking the time to assist me, OpenPnP is working now.

My thinking with the axis naming was that I can't use the same axis letters for the commands I send to both controllers, or else, I'll have both of them perform a move when only one of them needs to adjust position. For example, If both the driver and sub-driver MOVE_TO_COMMAND have the X axis defined, but the driver contrlos the cartesian table X motion and the sub driver controls nozzle#1 rotation, when I send something like G0 X10, the nozzle will move too. With my modification I can use two or more unmodified 3-axis GRBLs (except for the character tweak) to control the cartesian table and the head independently. Does this make sense to you or there's something I'm still not getting?

[Jason von Nieda]

Hi Gino,

No, the axis names that the controller supports doesn't matter. OpenPnP "maps" it's internal axes to whatever you define and they do not mix across sub-drivers.

So, here is an example of a perfectly valid configuration:

Grbl #1: /dev/tty.usbserial1

Axis Mappings: X, Y, Rotation1

MOVE_TO_COMMAND: G0 {X:X} {Y:Y} {Rotation:Z}

Grbl #2: /dev/tty.usbserial2

Axis Mappings: Z, Rotation2

MOVE_TO_COMMAND: G0 {Z:X} {Rotation:X}

So, if OpenPnP wants to move nozzle 1 to X = 10, Y = 20, Z = 30, Rotation = 40 the command will first be sent to Grbl #1. Grbl #1 will map X, Y, Rotation 1 to X, Y, Z and send G0 X10 Y20 Z40. Then the command will go to Grbl #2 and Grbl #2 will map Z only, because we're rotating nozzle 1 and not nozzle 2 and will send G0 X30.

OpenPnP's axes are completely independent of the controller's axes. You could map X = Y, Y = DOG, Z = Q, Rotation = FOOBAR, if you wanted. OpenPnP doesn't care.

Another way to put it is: Trust me, you don't have to modify Grbl. Keep working through your configuration and ask questions as needed. It will all work :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e6bdf512-d12e-4475-a957-64c651399387%40googlegroups.com.

[Gino Magarotto]

Many thanks for the explanation, Jason, I wasn't parsing correclty the OpenPnP command structure, but I understand now. I'll finish configuring this stuff and see if any other issue arises.

I feel I'll be able to get my machine running very soon, Now I just need to get the feeder PCB done to start integrating the auto feeders!

[Alastair Young]

Hi Gino,

I am building a similar system with two nanos running grbl 1.1 and I just ran into this problem a couple days ago.

In my case I have xyz on obe and rotation on the other

The trick is to define the Rotation axis in the sub-driver, which has its serial set to the second arduino. The rotation driver is wired to the X step/direction on this arduino. Then in the gcode for move on the subdriver you use code to send the rotation function to the X, something like

G1 {Rotation:X%f.4} etc

I'll post my machine.xml later as I'm thumbing this on my phone.

Point is, the subdriver grbl is calling the axis X but openpnp is using that X as Rotation.

It does seem that the main driver completes first before the subdriver command is sent.

[Alastair Young]

In other words, what Jason said.

[Gino Magarotto]

Yup, I was able to get my machine running using that command structure. I feel running the machine with two controllers affords quite a bit of flexibility. The heads can become interchangeable, and the final user can reuse existing CNC platforms with little work. Also, It's way easier to wire the machine this way, as just power and USB need to go to the head.