VersaMax Multidrop Problem

Hi Everyone,

I have one problem when i'm trying to write a driver to communicate with multiple VersaMax PLCs. My driver able to read and write to single PLC successfully. When it comes to multidrop, i got problems.

--------
| PC |------||----------------------------------
-------- | |
-------- --------
| PLC1 | | PLC2 |
-------- --------

|| = HE693SNP232(Convertor from RS232 to RS422)

In my test program, I have 2 buttons to read / write to PLC. For eg, Button1 for PLC1 and Button2 for PLC2. When I read from PLC1 then read from PLC2, I able to read PLC1 only but not PLC2. The problem is: after I read from PLC1, PLC2 doesn't work already.
If I remove the convertor, my application able to read both PLCs successfully. That's meant my application is working without convertor and is not working with convertor. I've tested the convertor with Cimplicity, it able to read PLCs with or without convertor. I've monitorred my cable. My application and cimplicity are sending same data to PLC but my one doesn't work. Can anyone tell me what's happenning? Any points that I have to concern? Thank you very much.

Regards,
Glen

I'm assuming you're using SNP. Did you send a 'Break' command to end the communications session with the first VersaMax before sending the 'Attach' command to start a session with the second? You send a 'Break' command by holding the transmit line in the 'space' state for longer than 2 character frames. The 'Break' command tells all slaves to get ready for an 'Attach' command.

'Break' command

Hi Steve,

Thanks for your help. I'm using break-free SNP for my communication. Actually i'm thinking about this as well, but i couldn't find any "break" command or "termination" command in the documentation (gfk-0529c).
I've monitorred data transmitted by Cimplicity. There were 3 bytes of zeros sent by Cimplicity and I did so in my program, but it doesn't work too. I assumed the a byte 0x00 represents "break" command, right?
"You send a 'Break' command by holding the transmit line in the 'space' state for longer than 2 character frames" - May I know more explanation on this?
Thank you.

Regards,
Goh

If you're writing your driver in VB, try this for the 'Break':

MSComm1.Break = True
Sleep 10
MSComm1.Break = False

Borland C++ Builder 5.0

Hi Steve,

I'm using Borland C++ Builder 5.0. I have no idea on this:

MSComm1.Break = True
Sleep 10
MSComm1.Break = False

What is MSComm1? I describe a bit my program. I open a comm. port with HANDLE comm_port, then send data byte by byte. For eg,

//my code
HANDLE comm_port = OpenCommunicationPort();
//assume
BYTE data[0] = 0x01;
BYTE data[1] = 0x02;
BYTE data[2] = 0x03;
BYTE data[3] = 0x04;
BYTE data[4] = 0x05;
//write to COM1 port
WriteFile(comm_port, &data, 5, &written, NULL);

Thank you.

Regards,
Goh

I don't know enough about Borland C++ to be able to offer any specific advice. When I said that you have hold the transmit line in the 'Space' state for longer than three character frames, I was quoting from GFK-0582. If you port parameters are 8 data bits, 1 parity bit, and 1 stop bit, that's 10 bits per character. At 19200 baud, 3 characters (30 bits) take a little more than 1.5 milliseconds (30 bits/ 19200 bits per second). With whatever commands you have at your disposal, you need to drive the transmit line to the 'Space' state. Whether 'Space' is high or low, I honestly don't know. Since there are only two choices, it's pretty simple to experiment to see which one works.

I suggest you download GFK-0582, It goes into a little more detail about the SNP protocol than GFK-0529. It also talks about waiting for one T4 time period after the Break before sending another 'Attach' to a different slave.

Thanks...

Hi Steve,

Thanks for your help. I think that I have solved my problem. I'm still testing on it, but it looks OK now. I used the functions SetCommBreak() and ClearCommBreak() which are corresponding to MsComm.Break.
Thank you.

Regards,
Goh

I am using Cimplicity 7.5 with GE versamax PLC.There is RS 232 to RS 485 converter between PLC & scada.yesterday everything is running condition.when we restart the PC the communication is not done.on hmi the old values are showing & but in alarm bar the currently alarms are indicated.when I stop the scada & run again the following services are failed.
1)DA_RP_Failed
2)DA_RC_Failed
3)PRT_DC_Failed
4)PRT_DS_Failed
5)TRK_RP_Failed
6)PRT_CNT_Failed

can you help me please i am in big trouble on site now?

Maybe can help but how does this relate to the OP from 2003?

bondre said:

I am using Cimplicity 7.5 with GE versamax PLC.There is RS 232 to RS 485 converter between PLC & scada.yesterday everything is running condition.when we restart the PC the communication is not done.on hmi the old values are showing & but in alarm bar the currently alarms are indicated.when I stop the scada & run again the following services are failed.
1)DA_RP_Failed
2)DA_RC_Failed
3)PRT_DC_Failed
4)PRT_DS_Failed
5)TRK_RP_Failed
6)PRT_CNT_Failed

can you help me please i am in big trouble on site now?

Click to expand...

Still need more details relating to what SCADA you have and what operating system it is running in.
What else has changed between the time it was working and the boot where it stopped?
How many OS updates were made?
What other software was installed?
What software was uninstalled?

RussB said:

Maybe can help but how does this relate to the OP from 2003?

Still need more details relating to what SCADA you have and what operating system it is running in.
What else has changed between the time it was working and the boot where it stopped?
How many OS updates were made?
What other software was installed?
What software was uninstalled?

Click to expand...

The operating system is windows XP & no software is installed apart from GE cimplicity & no software is uninstalled.only just restart the pc.After restarting the PC the communication is break.On that PC there is no internet connection for updates the OS.only one OS is there.