EXCOM Protocol

[Bryll 31]

Hello, I have a delicate task in front of me at the moment. Communication with a couple of old Stalelectronic 700 control systems for refrigerant compressors. So I need as much information about the Excom communication protocol as I can get. This is an old protocol, but it's new to me. Anyone that have any info about it ? The info I found this far is that it's an ASCII protocol of some kind. I'm planning to use a FX3U CPU with a FX3U-485BD communication card, and use "Non Protocol" to built some library blocks to handle communication with the RS/RS2 instructions. Any better idea ?

[kaare_t 155]

After a quick google search it seems it is a Turck protocol. You should contact them and ask. For all we know it could be a proprietary protocol, hence no public specification... As for NoProtocol and FX-series it should be no problem setting up an ASCII protocol as long as you have the spec.

[Bryll 31]

I'm currently working on this project again, the customer put it on hold for a couple of months. The data to and from the external devices is in ASCII. Data returned can be in boolean, integer value and real value. Boolean data can look like this: #00000000 to #FFFFFFFF. Real values can look like this: 1.2E-38 to 3.4E38. Integer values can look like this: -2147483648 to 2147483647. What I have to do is to decode it and store the result in a 32-bit register. Boolean data no problem, but does anyone have any good idea how to decode the real data and store it ? Same for the Integer values? I'm currently working on a FOR - NEXT loop to decode the data, since the RS2 function puts every ASCII character in separate registers. Any idea would be much appreciated

[Bryll 31]

DEVAL would do the job for the real values I think

[Bryll 31]

DDABIN seems to be the correct one for the Int. decimal value

[kaare_t 155]

Did you get the FOR-NEXT working, or do you still need pointers?

[Bryll 31]

I'm not really there yet. This is a part of a project I try to prepare in advance. Guess I need to use pointers and the FOR - Next loop. A read command (without CRC) can look like this: "LineFeed" <010203RD -41"CarriageReturn" (there is a SPACE CHAR [0x20] between RD and -41) < = Direction of message, < = command from master, > = reply from slave. 01 = Network Number 02 = Node Number 03 = Message Id RD = Read Command -41 = Real Value Register 1 The reply (if OK) will look like this: "LineFeed">010203OK -1.23400E+01"CarriageReturn" (the space is here placed behind OK) If the master sends a CRC, is it placed before the "CR" and can look like this "&D5". The slave will then reply with a CRC as well. It would be nice to have some hardware to try this out on, but I guess I have to do it with the customer standing behind me breathing in my neck

[kaare_t 155]

OK, do you know how to do a FOR-NEXT loop over the received bytes? Also; I see that the REAL values come in the format of ...E+.. (E-notation) Is this correct? Do they come like this in ASCII clear text? If so you might have a problem decoding them to actual REAL values in the PLC since this format is only used for viewing in the prog software. In the PLC it's of course a binary combination, so that might give you some problems.... However if you're not going to use the values for anything interesting in the PLC you don't have to worry.

[Bryll 31]

I have no problem with the FOR-NEXT loop, used it before. But, regarding the floating point values do I have to worry All the interesting temperature and pressure data I have to use to control the capacity of the units are in this REAL value. It might be a challenge

[Bryll 31]

What I can see in the manual, should the function DEVAL do the job just fine converting the E-notation ASCII string value to binary floating point

[kaare_t 155]

Never used it before but it looks promising. I would implement some manual controls before doing EVALS over the data, like a FOR-NEXT loop to check for only ASCII 0x30-0x39 and "E" and "+"/"-" /"." to ensure that noe error occurs when processing the instruction. In addition, make sure to handle any errors that might occur and test the code both without errors (as it should be from your peripheral device) and WITH errors to check for all possibilities, and ensure that the PLC never stops caused by any errors in the communication.

[Bryll 31]

Before the requested "data string" is decoded with a FOR-NEXT loop have I checked that the following is the same I asked for: Network number Node number Message ID (same ID sent by master, shall be returned by slave) Command (OK) Recieved data is not abnormal and of the same type I asked for (Bool, DINT or REAL). If any of the above is incorrect, will I set an error code and jump out of the RX routine. Data will be requested one more time from the slave, if incorrect a second time will an alarm be given, and jump to next TX message. Haven't decided yet if CRC is needed or not. Got the information from the customer that he will scrap one machine and send me the control unit for evaluation of the protocol. Makes life a bit easier I guess

[kaare_t 155]

I strongly recommend using CRC, or else databytes (containing the actual values) can be changed/altered/swapped without you noticing hence leading to wrong value(s). This can be caused by wrong data from the slave, noise on the line, wrong resistors and so on.... Use CRC!

[Bryll 31]

I'm now working on this project again. The customer stalled it a couple of times Since the protocol only accepts ASCII characters, do I need to convert my REAL data to ASCII. I have checked the "REAL_TO_STR" function, and it works as it should. The thing is that I need to break out the characters and put them in separate registers, so I can remove blank spaces (0x20) and put them in to the communication string at the correct place. Any good idea how to do this ?

[kaare_t 155]

Check out string instructions RIGHT and LEFT if I remember correctly... Removes x characters from the left or from the right position.

[Bryll 31]

I'm now testing my protocol, but I must admit that I've been more succesful with other things. The PLC gives me an Error at step 9469, with the code 6630 (SRET or IRET not found) When I look in the "Melsec Code Of Networks" can I see SRET at step 9469. I don't use any interrupts, so I should not need any IRET. Any idea ? Edit: This is how the code looks after I removed all other code, so the error is at step 3699 now. (* Excom_StalElectronic700: FX3U_Stal_Excom_Serial [FB] *) (* MELSEC code of NW #8 in Excom_Master_Ch1.Stal_Excom_Serial_Communication *) (* Code generated at 2014-03-21 14:25:19, 13 steps, 3513 steps for the whole object *) LD M3914 (* 3687 *) OR M3879 (* 3690 *) PLS M3877 (* 3693 *) RST M3906 (* 3696 *) SRET (* 3699 *) Edited 21 Mar 2014 by Bryll

[kaare_t 155]

1. You are sure that you don't need the IRET? 2. You are sure that you actually need the SRET?

[Bryll 31]

I finally found the problem. When I selected "Use with EN/ENO" in the properties when I created a function block, did I miss that "Use MC/MCR" is also activated by default when selecting "EN/ENO" option. Guess how long time stupid spent to find it

[Bryll 31]

The protocol is up and running I'm communicating with 5 different units, asking for 15 registers one by one from each unit. The protocol only allows me to ask for single registers, makes it very slow. But, at least it's working. Thanks kaare_t for your thoughts, much appreciated