Custom GCode subdriver

[Marius Liebenberg]

Hi

I am using an Atmega2560 to read my vacuum gauges and to turn on the lights for the cameras and control the solenoid valves etc.

I have to write the code for this so I want to keep it as simple as possible.

I have been looking at the the Gcode driver examples and the wiki but I think I am missing the just of the story.

So a couple of questions to try and get my head around this thing.

1) Can I specify my own M codes for my controller?

2) Must it be M or G codes or can I use any other code of my choice? Like and "S" or anything else.

3) I am using a serial command parser that needs a space between command and parameters. Is this a problem?

Any information of links that will help me understand will be welcome.

[Jason von Nieda]

Hi Marius,

1. Yes, you can use any text.

2. See #1.

3. See #1 :)

In short, the GcodeDriver is basically a serial port driven text command and response parser. It sends whatever text you specify for a given function, and it reads the response using Regular Expressions that you also specify. There are variables you can include in the text for things like X,Y,Z,C position, actuator state, etc.

Sub-Drivers are simply additional instances of the GcodeDriver connected to a different serial port. Each GcodeDriver connects to one port and controls one board, but you can have any number of additional GcodeDrivers in the form of Sub-Drivers.

The best documentation is at https://github.com/openpnp/openpnp/wiki/GcodeDriver, and I recommend also reading through some of the examples at https://github.com/openpnp/openpnp/wiki/GcodeDriver%3A-Example-Configurations. In particular, the Sub-Driver Example is an exact model of what you are doing.

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/15ee9035-08fd-4c45-925a-f0123cb8cfc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marius Liebenberg]

Hi Jason

Thanks for the reply. I think I have an better understanding now. I will code a simple command and test that. From there it should be easy.

[Marius Liebenberg]

Another question please.

If the actuators are spread between two boards and lets say the PLACE_COMMAND asks for the first actuator, situated on the sub driver to be used and then another on the main driver and visa versa. Is it correct that because the main driver does not have the actuator command it will pass it on to the sub driver meaning that I place all the commands for a specific action in both the main driver and the sub driver in order for things to happen in a specific sequence and time?

Do I have this right or is there a proper way to synchronize events?

[Jason von Nieda]

Order is main driver and then subdrivers in order of addition to the config. If a particular driver doesn’t have a command it is simply ignored for that driver.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c6cbd591-a02f-4489-aef0-f3382c915a8d%40googlegroups.com.

[Bernd Walter]

On Monday, June 4, 2018 at 7:56:18 PM UTC+2, Marius Liebenberg wrote:

Another question please.

If the actuators are spread between two boards and lets say the PLACE_COMMAND asks for the first actuator, situated on the sub driver to be used and then another on the main driver and visa versa. Is it correct that because the main driver does not have the actuator command it will pass it on to the sub driver meaning that I place all the commands for a specific action in both the main driver and the sub driver in order for things to happen in a specific sequence and time?

All (sub)drivers will get all requests.
If they have a command it will be issued, if no command is defined, then not.
I havn't tested the order, but I assume it is static with driver first, then subdrivers in definition order.
The commands are serialized until acknowledged (typical with an "ok line), not send parallel.