0

I encountered a problem that took me too much time, but without resolving it.soI really want you to help me.

I have an application built with c # wpf, and communicates with ovens via serial port.

the frame I need to send have following form: [EOT] (GID) (UID) (Temp) [ENQ] gid uid: group identifier and unit identifier (address of the machine). (eof),(enq) :frames the message. (temp) means: give me the temperature value.

the only machine that has the same address can answer (master slave architecture).

the form of the response message is: [STX] (Temp) <DATA> [ETX]. the field contain only the temperature value stx start text. etx end text.

I have no problem with sending and receiving of data, and I can display the value of temperature for a single machine connected. but when I connect More machines, I do not know which machine has answered the frame that I sent, because the response frame does not have any adress so that I can determine which oven have respond.

So the situation in brief is:
-I send Data to ovens.
- I received data.
- I can not decide which oven answered.
please any one have an idea. PS: I work with the protocol:EI-BISYNCH of eurotherm EuroTherm

If needed: EI-Bisynch ASCII Sequence Diagrams

user1202382
  • 27
  • 6
  • Well, you know who you sent the request to, so if the sender isn't identified in the response it seems the only course of action is to wait for the response before sending a new request. – 500 - Internal Server Error Feb 14 '12 at 20:59
  • @500 - Internal Server Error : The problem here is that I send to everyone, from a loop. and some machines may be offline or off so they can't respond – user1202382 Feb 14 '12 at 21:29
  • SerialPort.PortName matches the machine. – Hans Passant Feb 16 '12 at 04:13
  • How many ovens? Isn't each oven connected to it's own serial port: COM1--> oven_1, COM2 --> oven_2, etc... In which case Hans answer is correct. In fact if this is true RS-232 serial COM using the COM ports then it has to be this way. Only other possibility would be RS-485 and you would know that because you would have to put a device address in the packet? – Neal Davis Dec 19 '16 at 20:04

3 Answers3

1

IN these situations, the machine that you addressed is responding (or at least its assumed to be) Single Master - Multi Slaves. Meaning :-

  • Master -> Hey #1 tell me your temp -> #1 SIR! YES SIR! 23 degrees!
  • Master -> Hey #2...

The idea is no other slave will respond. By convention of the protocol.

Its pretty hard to do anything but this kind of system on serial.

In terms of Design if you create something like a command queue. Each command knows what device it wants to talk to, and what question it wants to ask. You process each command, send the serial message, get the response, and give it back to the command. Now you have a command, which knows which device it talked to, and what the response of that device was.

Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156
  • +1: Note that if the OP is using the MODBUS RTU version then all slave responses should include the slave address, data and check sum values. – NotMe Feb 14 '12 at 21:21
  • @Keith Nicholas: can you please give some more explanation or code. because i'm not really an mvvm expert.@ Chris Lively: no we use ELbisynch – user1202382 Feb 14 '12 at 21:34
1

In these conditions, the typical solution is:

  1. Send the request to the current device
  2. Wait for an answer for a defined timeout
    • If we receive an an answer within the timeout, the device responded.
    • If we do not receive an answer, the device is offline, mark it as such.
  3. Switch to the next device, goto 1

Basically you should be able to wrap into a loop the code described here: Providing Asynchronous Serial Port Communication

That is a sample that works with an AutoResetEvent. One of the .Net multithreading that allows synchronizing threads (the threads that sends the request in the loop, and the threads that receive the message in the loop)

Community
  • 1
  • 1
Vincent Hubert
  • 1,386
  • 9
  • 23
0

As long as you only have one "in-flight" command to which you are waiting for a response, and you know which device you sent the command to, you can assume that the device that responds next is the device you asked to respond. Now this won't necessarily always be true if it is possible for your device to send un-prompted responses.

Shane Wealti
  • 2,252
  • 3
  • 19
  • 33