Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: sgsims on March 27, 2024, 07:19:47 AM
-
Hello:
Can the StreamIn instruction capture data in a string literal format in addition to ASCII Hex format? For example if I want someone to send me a "False" string will either of these formats work?
0x460x410x4c0x530x450xa
"FALSE"0x0a
Thx
-
Hello:
Can the StreamIn instruction capture data in a string literal format in addition to ASCII Hex format? For example if I want someone to send me a "False" string will either of these formats work?
0x460x410x4c0x530x450xa
"FALSE"0x0a
Thx
It just captures BYTEs into a buffer or string. No formatting. If there is any formatting, it must be done by the device SENDING the data (e.g. Modbus has a binary form RTU and an ASCII form, although not many devices send out ASCII any longer).
Regardless, put it in a STRING e.g. SS0 or SL0 if it's long, then utilize STRFIND to find "FALSE" or "TRUE" or "HLO" or whatever and other String functions (e.g. STRSUB to get a substring STR2INT to convert text to its numeric equivalent, e.g. "123" is 123, et. al.
What's best for getting good answers, get the ENTIRE contents of the STREAMIN packet into a String, then post the QUOTED FORMAT contents here, e.g.
"FALSE,1,2$0A$0D" (whatever)
2 or 3 examples will be helpful. OR if there is a .pdf that describes the format of the data from the sending device, that would be best (grammar is one thing, semantics is the other).
-
Yup?the problem I?m having is the data being sent that I am attempting to capture using the STREAMIN instruction is throwing the ?On Error? jump to stage bit to go high so I can?t get the data into the SS1 memory location I specified in the instruction.
My assumption was the error was due to the format of the string being sent. The sendor says he is sending me False\r . In reality I don?t know what sort of bytes he is sending because I can?t see it in SS1 due to the error.
-
take a screen shot of the whole rung of your STREAMIN instruction. The Termination character should be just 1 exact character, and make it $0D (CR or \r)
-
Here you go.
-
Hmm... that looks ok.
So S10 is turning ON, not S6?
-
sgsims, you should not execute the STREAMIN until you have data in the buffer. So, before executing that Stage, wait until the .InQueue has a value greater than zero in it.
-
franji...yes S10 is turnng on not S6......
-
So at the end of the day if I am asking someone to send me string that I can capture successfully with the STREAMIN instruction am I really saying send me the binary equivalent of the ascii character they intend to communicate? I guess I?m assuming that the error was being generated as a result of bad data format. But then I?m thing that no matter what they send is seen by the instruction as a binary bit pattern so that would give me the correct data would result in a successful communication as far as the STREAMIN instruction goes.
-
So at the end of the day if I am asking someone to send me string that I can capture successfully with the STREAMIN instruction am I really saying send me the binary equivalent of the ascii character they intend to communicate? I guess I?m assuming that the error was being generated as a result of bad data format. But then I?m thing that no matter what they send is seen by the instruction as a binary bit pattern so that would give me the correct data would result in a successful communication as far as the STREAMIN instruction goes.
Yes. Have you tried Greg's suggestion? I think that is your issue.
-
I didn?t try Greg?s suggestion as the program has been in service for over 6 years and working like a champ. The issue now stems from a change in the customer?s ERP who I am communicating with.
That being said Greg?s suggestion is a good one that I will implement in this program.
Now I think the issue might be the bit pattern being used for the delimiter.
-
Now I think the issue might be the bit pattern being used for the delimiter.
The format of the message is important. If it is no longer terminated with just a CR (possibly CR/LF?), that would require a tweak to the STREAMIN instruction.
If you can hook up a communication analyzer - there's PC software out there that can do it - to see exactly what is being sent.
Double check the baud rate, data bits, parity settings, etc. on BOTH sides. Cabling could be in question, handshake, et. al.
-
The message is still being terminated, or at least attempted to terminate, with a CR but could be the bit pattern used to send that character. I will look into the analyzer and check the parity, stop bits etc. I assumed all of that was fine because we were able to send the host a string without issue.
-
I assumed all of that was fine because we were able to send the host a string without issue.
STREAMOUT will send with success regardless of whether it was received or not, or whether baud rate/parity etc. are correct on the receiving side. You are doing raw comm, not a formal protocol in firmware like MRX/MWX where there are rules and handshaking and timeout behaviors in the firmware state machine can report more valid success/error.
-
Thanks Franji,
So the Error gets thrown with the STREAMIN instruction if the comm was not complete which could be many things including the two I am focusing on now?
1- Proper Delimiter
2-RS232 Config stuff..STop Bit, PArity etc.
Thanks for all the help with this!
-
Is there a way to see the message payload into the Queue if my StreamIn instruction is throwing an error bit?
-
Is there a way to see the message payload into the Queue if my StreamIn instruction is throwing an error bit?
Currently, no. However, just about the only thing I can think of that can cause the STREAMIN error, is a timeout. This would mean that you have the parameter, "Network Timeout" checked in the instruction, and that time is reached before the "Complete when..." requirements are met. In other words, you enable the STREAMIN instruction and the timeout starts. You, let's say, have the instruction configured to complete when 10 bytes are received, but you only receive 8. Then the timeout will happen and an error will occur. Or you have the instruction configured to complete when it gets its delimiters of CR, LF, and you never get those characters. Then the timeout will happen and an error will occur.
This is why I recommended never executing the STREAMIN until there is data in the .InQueue structure member (i.e. > 0).
Someone can correct me if I'm wrong, but that's about the only thing I've seen as far as the STREAMIN throwing an error... it's a timeout.
-
Thanks Greg...I think that is what is happening in my case I have a timeout specified and the instruction to complete when either of 2 delimiters are received. I do have logic in place that enables the Streamin instruction upon seeing data in the queue....so pretty sure something is getting intop the queue. My suspision is that the bit pattern they are sending to represent the delimiter is not correct so the instruction is hanging until the tiemout limit is reached.
Another question....when / how is the queue cleared? if data goes into the queue does it stay until the streamin instruction completes with either a succes or failure?
-
Another question....when / how is the queue cleared?
Make sure you have FLUSH INPUT DEVICE checkbox CHECKED in the STREAMOUT instruction
if data goes into the queue does it stay until the streamin instruction completes with either a succes or failure?
Yes. This is why you should FLUSH it just in case there are any "old" characters in there from the last time.
-
Guess I need to readup on the queue particulars ..sounds like the same queue is used for out going and incoming data
-
Is there a way to see the message payload into the Queue if my StreamIn instruction is throwing an error bit?
I was playing with this a little, and what I did was send 10 bytes to my BRX built-in port, including a carriage return & linefeed. Then for my STREAMIN, I configured it to just retrieve 1 byte with no delimiters. That allowed me, through multiple execution of the same STREAMIN instruction, to get 1 byte at a time out of the input queue. In this manner I could see exactly what was transmitted.
You could do the same and you could see exactly what your program is sending to your SERIO port.
-
Here is what I mean...
Pay no attention to the name, "TCP_ex"... you would use the name of your Device instead, of course.
-
Got it..so I just connect a serial cable from one port on the BRX to a 2nd port on the same BRX and send messages back and forth? Genius