GcodeDriver serial port write error sending second $ex=1 to TinyG

[V Bruce Hunt]

I'm a novice attempting to configure my LitePlacer to use OpenPNP.   The

Issues & Solutions tab suggests using XON/XOFF flow control to communicate to the controller (TinyG) from the driver(GcodeDriver).  When I start the PNP machine, the CONNECT command as it's first line sends the "$ex=1" line to the TinyG along with a host of other TinyG config. and Gcode commands.  "$ex=1" configures the TinyG to use XON/XOFF flow control.  The CONNECT command appears to go well and the next command sent is a "$ex=1".  This results in the following error:

2021-08-17 19:03:21.626 GcodeDriver ERROR: serial://COM4 failed to write command $ex=1: java.io.IOException: Write error.
    at org.openpnp.machine.reference.driver.SerialPortCommunications.writeBytes(SerialPortCommunications.java:154)
    at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.writeLine(ReferenceDriverCommunications.java:75)
    at org.openpnp.machine.reference.driver.GcodeDriver.sendCommand(GcodeDriver.java:1005)
    at org.openpnp.machine.reference.driver.GcodeDriver.sendGcode(GcodeDriver.java:979)
    at org.openpnp.machine.reference.driver.GcodeDriver.sendGcode(GcodeDriver.java:961)
    at org.openpnp.machine.reference.driver.GcodeDriver.connect(GcodeDriver.java:379)
    at org.openpnp.machine.reference.driver.GcodeDriver.setEnabled(GcodeDriver.java:401)
    at org.openpnp.machine.reference.ReferenceMachine.setEnabled(ReferenceMachine.java:194)
    at org.openpnp.gui.MachineControlsPanel$2.lambda$actionPerformed$1(MachineControlsPanel.java:292)
    at java.lang.Thread.run(Unknown Source)
2021-08-17 19:03:21.626 GcodeDriver$ReaderThread ERROR: Read error: java.io.IOException: Read error.
    at org.openpnp.machine.reference.driver.SerialPortCommunications.read(SerialPortCommunications.java:143)
    at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readUntil(ReferenceDriverCommunications.java:91)
    at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readLine(ReferenceDriverCommunications.java:71)
    at org.openpnp.machine.reference.driver.GcodeDriver$ReaderThread.run(GcodeDriver.java:1208)

When I test the $ex=1 command (stand-alone) using CoolTerm, I get the following response:

$ex=1
[ex]  enable flow control         1 [0=off,1=XON/XOFF, 2=RTS/CTS]
tinyg [mm] ok>

I suspect that the GcodeDriver does not know how to parse the TinyG response and this is what causes the I/O read error.  In light of me being a novice at OpenPNP, is this a correct understanding of the issue; or have I made a basic configuration error? Any help in understanding and then resolving the problem would be appreciated.

[ma...@makr.zone]

Hi Bruce,

Two thoughts:

1. Issues & Solutions should also suggest to set the driver inside OpenPnP to XON/XOFF, right?
2. Sending $ex=1 is actually a bit of a Chicken and Egg situation. If XON/XOFF is already set on the driver, but the controller is still on something else, then it will likely fail. If XON/XOFF is not yet set on the driver, then the setting of $ex=1 will change the controller's flow control in mid-stride, so it is expected to fail too, immediately afterwards. But if you then set the driver to XON/XOFF afterwards, it will work again.
   

Sending all these settings on each connect, is some sort of tradition with TinyG, that I (had to) embrace(d), when creating Issues & Solutions. But I don't think it is actually a good idea, especially for $ex. This should be done externally, once, and the settings script kept around separately, as a file. Like for other controllers. The CONNECT_COMMAND should only do transient stuff.

_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/f6eacf50-f990-498f-8473-9263733a311an%40googlegroups.com.

[V Bruce Hunt]

In regards to "Two thoughts":

1. Issues & Solutions does indeed suggest to set the driver inside OpenPnP to XON/XOFF.
2. Chicken & Egg indeed.  I've tried a couple of simple experiments.  Using CoolTerm I cannot get a properly formed $ex command to fail.  I've tried $ex with parameters 0,1,2 and even a no parameter $ex and it does not fail.  I suggest that the following protocol would therefore always work.  The $ex <value> command is only sent if the driver had read as the most recent response the prompt "tinyg [mm] ok><return>" and has NOT transmitted any characters  to the controller since receiving the "tinyg [mm] ok><return>". 
   

In other behavioral observations:  It appears that if you accept the Issues & Solutions recommendation to use XON/XOFF flow control,  from then on the driver always sends "$ex=1" regardless of the value of "flow-control" attribute on the serial element contained in the driver element.  The following is the serial element in my driver element in machine.xml:

<serial line-ending-type="LF" port-name="COM4" baud="115200" flow-control="Off" data-bits="Eight" stop-bits="One" parity="None" set-dtr="false" set-rts="false" name="SerialPortCommunications"/>

And here is the resulting partial log after starting the PnP machine:

2021-08-18 00:37:52.099 GcodeDriver DEBUG: [serial://COM4] >> G21 M9, 5000

(The above is the last line emitted for the CONNECT_COMMAND.)

2021-08-18 00:37:55.115 GcodeDriver DEBUG: [serial://COM4] >> $ex=1, 5000
2021-08-18 00:37:55.116 GcodeDriver$ReaderThread ERROR: Read error: java.io.IOException: Read error.

    at org.openpnp.machine.reference.driver.SerialPortCommunications.read(SerialPortCommunications.java:143)
    at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readUntil(ReferenceDriverCommunications.java:91)
    at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readLine(ReferenceDriverCommunications.java:71)
    at org.openpnp.machine.reference.driver.GcodeDriver$ReaderThread.run(GcodeDriver.java:1208)

2021-08-18 00:37:55.116 GcodeDriver ERROR: serial://COM4 failed to write command $ex=1: java.io.IOException: Write error.

    at org.openpnp.machine.reference.driver.SerialPortCommunications.writeBytes(SerialPortCommunications.java:154)
    at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.writeLine(ReferenceDriverCommunications.java:75)
    at org.openpnp.machine.reference.driver.GcodeDriver.sendCommand(GcodeDriver.java:1005)
    at org.openpnp.machine.reference.driver.GcodeDriver.sendGcode(GcodeDriver.java:979)
    at org.openpnp.machine.reference.driver.GcodeDriver.sendGcode(GcodeDriver.java:961)
    at org.openpnp.machine.reference.driver.GcodeDriver.connect(GcodeDriver.java:379)
    at org.openpnp.machine.reference.driver.GcodeDriver.setEnabled(GcodeDriver.java:401)
    at org.openpnp.machine.reference.ReferenceMachine.setEnabled(ReferenceMachine.java:194)
    at org.openpnp.gui.MachineControlsPanel$2.lambda$actionPerformed$1(MachineControlsPanel.java:292)
    at java.lang.Thread.run(Unknown Source)

The above $ex=1,5000 is NOT in the CONNECT_COMMAND. 

I'm also wondering if the read error IOException is thrown for both physical data corruption (e.g. parity, invalid stop bits) and a regex matching failure.  Perhaps there should be an "Unexpected Controller response" exception for the latter case.

Thanks for helping me understand what is going on.

[ma...@makr.zone]

Hi Bruce,

> Using CoolTerm I cannot get a properly formed $ex command to fail. 

Try setting CoolTerm to different flow control settings explicitly, and then retry your experiment. Does this work?

If yes, there may be some additional auto-dicovery-flow-control "magic" in there, that is reasonable for such a terminal program to have. But it is beyond the job description of OpenPnP. Configuring flow-control on your controller side is not OpenPnP's business, is it? 😉

> if you accept the Issues & Solutions recommendation to use XON/XOFF flow control,  from then on the driver always sends "$ex=1" regardless of the value of "flow-control" attribute

No, the two are not coupled. It just sends whatever is in the CONNECT_COMMAND (or wherever you have it), blindly. You have to accept both the G-code and the Flow control suggestion of Issues & Solutions for it to correspond.

> The above $ex=1,5000 is NOT in the CONNECT_COMMAND. 

Well, then have a look at the ENABLE_COMMAND, but that would be [twice] wrong. Btw. that ",5000" part is the milliseconds timeout argument inside OpenPnP, it won't appear as such in the command, nor will it be sent to the controller, so just look for $ex=1

> I suggest that the following protocol ..

I doubt this will help, we would have to disconnect after that command and then reconnect using the changed driver flow control. But like I said, this is not OpenPnP's business (and it would be useless and slow to repeat on each connect, if the setting was already correct before).

Just set $ex=1 once using CoolTerm and then remove it from any command in OpenPnP.

Learning from this discussion, I will remove $ex=1 from being proposed for fresh TinyG configurations, it will only be proposed to replace any pre-existing (wrong) $ex=0 or $ex=2 commands.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d6e54793-92dc-49bc-95f4-e46dc340364fn%40googlegroups.com.

[V Bruce Hunt]

Hi Mark,

Thanks for the excellent comments & suggestions.  Here is what I've tried so far:

> Try setting CoolTerm to different flow control settings explicitly, and then retry your experiment. Does this work?

I tried explicitly setting CoolTerm to the following flow controls before running the $ex experiment:

• None -- TinyG's response to $ex was unchanged.
• XON/XOFF  -- TinyG's response to $ex was unchanged.
• RTS/CTS -- TinyG's response to $ex was unchanged.
• DTR asserted -- TinyG's response to $ex was unchanged.
• DTR not asserted -- TinyG's response to $ex was unchanged.

I saw no change in TinyG's behavior regardless of the CoolTerm Flow Control settings.

I saw the following behavior of TinyG's response to the $ex configuration variable setting:

• $ex -- $ex <lf> [ex]  enable flow control         <current value> [0=off,1=XON/XOFF, 2=RTS/CTS] <lf>tinyg [mm] ok>
• $ex=1 -- $ex=1<lf>[ex]  enable flow control         1 [0=off,1=XON/XOFF, 2=RTS/CTS] <lf> tinyg [mm] ok>
  
• $ex=0 -- $ex=0 <lf> [ex]  enable flow control         0 [0=off,1=XON/XOFF, 2=RTS/CTS] <lf> tinyg [mm] ok>
  
• $ex=2 -- $ex=2 <lf> ex]  enable flow control         2 [0=off,1=XON/XOFF, 2=RTS/CTS] <lf> tinyg [mm] ok>
  
• $ex=3 -- $ex=3 <lf> [ex]  enable flow control         3 [0=off,1=XON/XOFF, 2=RTS/CTS] <lf> tinyg [mm] err: Input value range error: $ex=3
  
• $ex=-1 -- $ex=-1 <lf> [ex]  enable flow control       255 [0=off,1=XON/XOFF, 2=RTS/CTS] <lf> tinyg [mm] ok>
  
• $ex=<number> -- In this case TinyG appears to convert fixed or floats to integer and extracts the rightmost 8 bits, range checks for values greater than 2 ( and issues the input value range error if greater than 2).  It permits all negative 8 bit 2's complement integers
  

where:

• <current value>  is the current value in the range  (-128..2) displayed as an unsigned integer (2,1,0,255..128).
• <lf> is a line feed (used to compact response for display)
• <number> is a integer,  fixed point number or float

To be complete, I have a TinyG with the following hardware and firmware:

         [fb]  firmware build               440.21

         [fv]  firmware version            0.97

         [hp]  hardware platform        1.00
         [hv]  hardware version           8.00
         [id]  TinyG ID                            7U4895-GYX

<end CoolTerm experiment>

> No, the two are not coupled. It just sends whatever is in the CONNECT_COMMAND (or wherever you have it), blindly. You have to accept both the G-code and the Flow control suggestion of Issues & Solutions for it to correspond.

I double checked the ENABLE_COMMAND and all the commands and there are no instances of "$ex" anywhere in my "machine.xml" and yet the driver emits a $ex=1 -- apparently appended to the CONNECT_COMMAND ( note the timing relative to previous Gcode / config variable differences).   What could explain the spurious $ex=1 being emitted?  In all my attempts to start the machine (i.e. click on the green start button)  the GcodeDriver emits $ex=1 right after emitting the CONNECT_COMMAND codes regardless of the driver flow control settings.  I've tried all the following:

• Closed OpenPNP; Edited "/.openpnp2/machine.xml" to remove all instances of "$ex" and set serial element flow control attribute to none; and then restarted OpenPNP. 
  
• Set flow control drop-down  to None using the GcodeDriver basic configuration panel in the OpenPNP Machine menu item.
• Set flow control drop-down to XON/XOFF using the GcodeDriver basic configuration panel in the OpenPNP Machine menu item.
• Set flow control drop-down to rts/cts using the GcodeDriver basic configuration panel in the OpenPNP Machine menu item.

None of these changes affect the driver emitting the spurious $ex=1 right after the CONNECT_COMMAND on a machine start.  I do not understand what is going on here.  Thanks much for helping me understand/ameliorate this nagging problem. 

Background Notes:  Using CoolTerm I have tested the LitePlacer and it moves in X,Y,Z and A.  In OpenPNP both camera's work.  If I can get the machine to turn on, I can make progress on completing the calibration and getting the LitePlacer up to a production test run. 

Bruce

[ma...@makr.zone]

> I saw no change in TinyG's behavior regardless of the CoolTerm Flow Control settings.

Possible explanation: You're never hitting a flow control situation (where the TinyG read or write buffer is full) in the first place. Whereas in OpenPnP this will likely happen, if you have the typical TinyG "let's set a gazillion of options at once" CONNECT_COMMAND. So it's no wonder CoolTerm will keep... erm ... cool.

Or there is some secret "magic" as I said before.

I would not spend more time pondering that. We need to get OpenPnP running not analyze CoolTerm.

> What could explain the spurious $ex=1 being emitted? 

I just searched the whole of OpenPnP and there is no $ex except where I described.

Something is "haunted", please send the machine.xml and a full log at TRACE level.

👻

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b0ef3014-6376-4286-93b6-d802ac66b3a9n%40googlegroups.com.

[V Bruce Hunt]

Hi Mark,

I owe you a big apology.  I thought I'd thoroughly checked "machine.xml" for $ex=1.  I had only thoroughly checked the GcodeDriver and NOT the GcodeAsyncDriver.  The GcodeAsyncDriver contains "$ex=1" in the CONNECT_COMMAND.  Darn! I guess I have to give up my belief in ghosts!  I apologize for missing that darn "$ex=1".  I'm chalking it up to a newbie mistake. 

To begin to make amends I first removed "$ex=1" from "machine.xml" and re-ran OpenPnP with debug logging.  Enclosed is "machine.xml"

with the offending "$ex=1" in the CONNECT_COMMAND in the GcodeAsyncDriver element.  Running OpenPnP with this "machine.xml" replicates my claimed ghostly behavior.  The enclosed log, "OpenPnPlog2108181728.txt" shows this behavior.

The above caused me to remove the "$ex=1" line from "machine.xml" and re-run OpenPnP with debug logging.  Well an error occurs, but it is on the first gcode/configuration line of the CONNECT_COMMAND in the GcodeAsyncDriver element.  This is shown in the enclosed log, "OpenPnPlog21081711.txt". 

Given this new information, I now suspect that the CONNECT_COMMAND 's from both GcodeDriver and GcodeAsyncDriver are being sent to the TinyG controller.  Notice that with the "$ex=1" CDATA removed from the GcodeAsyncDriver OpenPnP now fails on the new first command of the GcodeAsyncDriver's CONNECT_COMMAND.  This failure is on "G21 ; Set millimeters mode" and that is the only place in "machine.xml" that it appears ( I swear, I triple checked it to make sure! ;-).

Again my apologies for the wild goose chase; but thanks for helping this newbie out!

/Bruce

[ma...@makr.zone]

> Given this new information, I now suspect that the CONNECT_COMMAND 's from both GcodeDriver and GcodeAsyncDriver are being sent to the TinyG controller. 

You mean they were configured on the same serial port? Yeah, that could explain all kinds of strange behavior, also depends on the OS where it fails, I guess.

If you don't use the second controller (yet) you need to either delete it or you can use this trick:

• Set comms to tcp
• Set port to exactly GcodeServer
  

This enables a virtual/simulated GcodeServer inside OpenPnP, this time a true 👻 in the box!

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2b66e746-e0a8-46a5-97d2-e421d8af698bn%40googlegroups.com.

[V Bruce Hunt]

Hi Mark,

A big thank you.  In "machine.xml" I removed "Drivers>GcodeAsyncDriver>" and now the machine connects with no errors  and I can now jog the head!    ( I know -- small steps.)

I realize now that I thought the first driver in the list was the only active driver.  Apparently, if you have two drivers defined in "machine.xml" they both are used.  I think thinking is a consequence of the fact that my PnP machine (LitePlacer) has only a single controller so I intuited that only a single controller would be active.  For us newbies this may seem natural (At least to me it did).  With a bit more understanding of OpenPnP,   I think the reason for multiple order possible drivers is that you may have multiple controllers on a larger scale PnP machine ( e.g. one for machine movement/component selection and one for component feeding.) and the order in which they are invoked may be important.

However, it seems to me that a brief explanation in the Wiki that includes an overview of how OpenPnP employs and invokes drivers including this important fact would go a long way toward eliminating confusion and errors in future OpenPnP novices.  I would be happy to write up such an explanation.  However, such a write-up would need significant editing and review before being made a proper part of the Wiki. 

Again, thanks for helping me through resolving this issue. On to Calibration!

/Bruce

[V Bruce Hunt]

I've updated the wiki > Driver Setup with new text to make Driver usage more clear and to correct a couple of typos.  Please review and correct.

/Bruce