OMG! I might have to use 'bytes at port'. How do I read EOT and ENQ serial transmission

[JÞB]

Oh yes Bert a termchar would be better! BUT, the FW Author didn't depend on any flow control at all!

They used a terminal emulator "crlf" just formats the response to the teletype paper output by returning the carriage and feeding a line.

Special characters like EOT and ENQ are three times as fast over the 77baud current loop! And, since they don't print anyway, why would you move the carriage or waste the whole line of paper? This is why nonprintable characters are used!

I'm afraid to try YOUR solutions on 1940's technology, next thing you'll want some fast voltage controlled switch device like a "Transistor."

[BertMcMahan]

Ahhh gotcha 🙂 I thought there was some dark magic you were using that termchars would get rid of. I didn't realize the device was quite so old 🙂

Now I'm imagining an actual paper terminal printing the \ | / -- sequence over and over again, just churning through reams of paper lol

[JÞB]

The device is not that old.  The FW for the terminal emulator got written into some textbook somewhere 80 years ago and just has never been updated.  You missed the backspaces in slash, bs, pipe, bs, backslash, bs, em dash, bs. "-" is an eye dash or minus I typed an error. Those backspaces help slow down the data to reasonable speed and do not waste lines of paper.

Dashes are named for width

See below*

mni

—–- are em dash, en dash, eye dash .

[STTAndy]

Just got back in from the weekend and I am blown away by the effort some people are willing to put in to help out.

First an apology for not elaborating more. The EOT is sent when the last dot is marked. The ENQ means the marker has returned to its home position. The two are not sent together.

There are a few solutions here to consider and in the interest of getting the job moving, because it is due to be completed early next week and I also have to create some comms to the PLC and some leak detecters to configure I will go with a simple switch to bytes at port after the RUN OK response. Option 2 from crossrulz seems to be the simplist way to go right now as my code is already looping checking for data to receive.

The system is not automated so any failures in the equipment or process will be captured by the operator. Marking is the final process in the cycle so if the EOT and ENQ are not recieved I will force some supervisor action to confirm the marking was completed and log the alarm. The end of the cycle will switch back to termination character.

I have other issues that need some attention so I really don't have time to try many things. I have been given a micro PC to deal with the marker communications because the PLC is incapable of dealing with virtual comm ports. Unfortunatly this PC cannot be configured to boot at power on so I also need to find a way to wake on lan from the PLC. No idea yet how that will work out, or even if its possible to send the 'magic packet' from the PLC.

Happy days.

I will come back to this thread when I am more comfortable with my work load and if there is time I may try out some other options. I am a little intrigued about binary mode.

[STTAndy]

Ok so I have used bytes at port because the responses from the unit are predictable enough that I will never have truncated data etc. By preventing any data being sent to the thing while expecting data to return should keep everything in control. If the expected responses are not recieved before a timeout then it resets.

Time is an issue so thats the why I am leaving it this way for this job. I tested it thoroughly and forced it into error conditions and it all works fine, plus this is only going to be 20 miles from here when installed so a visit after delivery is easily done if any issues arise.

I have marked the solution and option 2 was the one.

Cheers

[STTAndy]

In case anyone is interested I couldn't get the micro PC to wake on lan from the PLC.

I believe I could get the PLC to send the packet but it seems WOL is not an option on the PC. I thought that was standard on all PCs, maybe this feature is being phased out, i don't know.

The manufacturer sent a bios update to include boot on power up so it got solved that way.