String communication Ethernet scale

[Graatje73]

Dear all,

At this moment I'm working at communication by Ethernet with a scale. The scale needs and STX before and an ETX behind every message. When I fill manually the MI string range, it works.
For status request I have to sent STX 0 ETX, in the MI range this is in hex 02 30 03. I sent this with TCP_raw, so far everyting works.

I tried to use the function create excel delimeted line, but in here there is no option to use no delimeter (delimeter 1 cannot be empty).

If I use the funtion string to asci a cannot type the non printable characters like STX and ETZ into the string.

I look also at config protocol, maybe I could use it to fill a string but this is assigned to a com port.

Is there an easy way to fill a string with the STX before and ETX behind?

A MI is 16 bits ( 2 bytes) contains 2 characters. Is there a way to fill only the MSB or LSB?

Thank you in advance,

Gerard

[Joe Tauser]

Have you looked at the Protocol TCP/IP blocks?   I think they will do what you need.

If you can attach your program to your post that would also be helpful.

Joe T.

[Graatje73]

Dear Joe,

Thank you for your response attached the test program. To get status information from the weighing device I have to sent STX 0 ETX.

So first I convert 0 to ASCI. Then I insert STX before it, and then ETX behind it. This I sent with TCP raw send.

If I do a scan with TCP raw scan, I got the requested data. The data is 12 characters. What I see sometime is that there are 24 characters available (2 times the status information) behind each other. I thought maybe it's better do a raw scan after a short period when I did the raw send, but that doesn't matter. If I monitor ethernet in setup mode, I see it also. Sometimes I got 2 status strings f the weighing device.

Socket 0 I configured for remote assistance or programming purposes. Socket 1 I configured to communicate with the weighing device.

All help/information appreciated!

regards,

Gerard

 

V1210 com test1.vlp

[Graatje73]

In addition to my previous email. I tried the Protocol TCP/IP. I cannot add the portnumber 50001, cannot go higher than 32767 (16bits).

regards,

Gerard

[Joe Tauser]

What kind of scale do you have?

Joe T.

[Graatje73]

Anritsu checkweigher

regards,

Gerard

[Ausman]

I'd first be breaking your nets up a bit, and then getting rid of timer usage.  For me there is too much going on in each rung.  I didn't delve deeply, but it's possible that you're actually asking  for 2 scans, that might occasionally be missed due to miniscule time differences.

[Graatje73]

Update, I changed the port number of the scale to 32049, because I cannot give in a higher port number in the TCP config protocol. Then I start using the TCP config protocol and this works convenient to build the string to sent.
Attached the test program. Anyway It seems that we miss one scan cycle. If you see the picture attached you see that the number of TX is not the same as the number of RX. In this case if I do one manual scan (M91) they become equal, I 'm able to read data again and then they are equal. I thought it needed a delay between the sent and scan function, there for a changed to a negative edge to start the scan function. Anybody an idea?

Is it a problem to do a scan every cycle (keep scanning)?

V1210 com test2.vlp

[Joe Tauser]

When you say "cycle" I'm guessing you mean every PLC scan.

Yes, that's a problem.  You can't do it without clogging up the buffer on the PLC.  The TCP protocol is by definition a handshaking protocol - when you send a request you have to wait for an answer, which probably explains why you have more transmits than receives in your picture.

I took a quick look at your code.   The protocol blocks are a higher level of complexity and it's easy to not implement the properly.

1.  The SCAN block is the listener and should be on the rail.  You're always listening.

2.  In the SCAN block, you only have one message (message 0) and the way you have it configured it will register if and only if it starts with hex 02 and ends with hex 03.  Put a second message in that is a string only and have it point to a different MI area.  Make its length twice as long as you anticipate so you don't miss any incoming messages.

3.  You need to verify that the socket is connected with a system bit before you call the SEND block.    

 

Try these out and let us know what you find.

Joe T.