DL06 Remote Start / Stop

[allscott]

If all else fails you could use one of these....


http://www.hw-group.com/download/IP_Relay_en.pdf

 

[plc noob]

check out these devices http://www.cpscom.com/gprod/cps.htmand this one http://www.opengear.com/product-ip-power.html

 

[Tark]

More than likely it’s not just a simple string that changes the PLC modes. I would assume that there are multiple messages (at least more than one) that the PLC would need to receive in order to change the PLC mode. And there’s a very good reason for this, consider that the comm port isn’t just use to communicate with DirectSoft, it’s also used to transmit/receive other messages be it Modbus, DirectNet, K-Sequence, ASCII. Granted these are different message protocols, but no matter the protocol the information being transmitted/received is just a bunch of bits. If changing the PLC mode was as simple as sending a simple string, then in all likely hood, AD would be receiving calls about their PLCs dropping out of Run mode and the reason would be that the message they sent to the PLC just so happened to match the same bit pattern that DirectSoft uses to change the PLC to Program mode.

There probably is a message to tell the PLC to enter some type of Edit/Program mode, which is used when connected with DirectSoft, in which the PLC would act upon another message that would change the PLC mode. So more than likely you would be looking at trying to figure out multiple messages that would need to be sent in order the change the PLC’s mode.

I have had something like this happen, although it didn’t affect the PLC. I was using leased line modems to transmit/receive data between (2) PLCs. Every few months the PLCs would lose communication with one another, it turned out that the leased line modems had reverted back to their factory default settings. I would reprogram the modems and everything started working again. The cause of the problem was that the modems were listening to the data being transmitted between the PLCs, and every so often a PLC message would just so happen to match the same bit pattern that the modem used to reset itself back to the factory default settings. I reprogrammed the modems to ignore all communication after 10 seconds and never had that problem again.

 

[milldrone]

I'm a little confused. If your concerned about the com port locking up how will you reset it by using the com port?

That said I did find this over on the automation direct forum. http://forum1.automationdirect.com/board/Forum5/HTML/000070.html
And the post is by our own Lancie 1.
[font=Arial, Helvetica, sans-serif]Lancie1[/font]
[font=Arial, Helvetica, sans-serif]Member [/font]

[font=Arial, Helvetica, sans-serif] [font=Arial, Helvetica, sans-serif]posted 02-10-2003 06:36 PM [/font][/font][font=Arial, Helvetica, sans-serif]Jay,[/font][font=Arial, Helvetica, sans-serif]I can only share your sorrow for most of your problems. I am having the same type of problem in communicating with a DL-06 through the serial comm port. For your item two, how to "reset" the port, I used the ACRB command (ASCII Clear Receive Buffer). Supposedly this deletes any data in the comm port buffer. But I am using the AIN (ASCII In) command, and I reset it by simply turning that rung off when the AIN Complete bit turns on, indicating that the AIN data read is finished.[/font]

The reason for this, is that sometimes the rs232 ports on the computer could (very rare) get locked up. In this event I have the ability to reboot the computer, but I can not 'reboot' the PLC, in case the PLC gets locked up.

Any help would be greatly appreciated.

 

[geniusintraining]

I'm a little confused. If your concerned about the com port locking up how will you reset it by using the com port?

milldrone,

This is what I was talking about in my post... his reply was that he does not want to reset the com port on the PLC, its the PC... but he wants to stop the PLC and reboot the PC, then enable the PLC.

I agree with (I think Ron said it) do a hand shake that if the PLC does not see this then it will be disabled.

I have done this with a piece of %^&# OPTO22, if I do not get the com input then I alarm out on the HMI and on another PLC (that has the bells and lights) you could do the samething...

Have another PLC that will reboot the PC if it does not get the signal , or you could buy a $200.00 PC that will work and not freeze up... but then we would have nothing to talk about

 

[rsdoran]

You could be redundant i.e. have each be able to reboot the other if it the comms do not handshake or whatever you setup. It is simple to have a plc wait for a handshake and restart at last position or from the beginning too.

 

[kittydog42]

I know that Port 1 is fixed at 9600 baud, 1 stop bit, odd parity, and works on Modbus out of the box. It may also be limited to being slave 1 only, but I am not sure of that. I don't know how that might pertain to this problem but it could help you in reading the messages.

 

[elevmike]

I'm not sure your addressing a legitimate concern. Have you tested PLC to PC comm recovery in the event of a PC re-boot?

I agree with Ron and some others here that you would not need to reboot the PLC, but in the event of comm loss, program the PLC to cause the comm port to stop sending data for a few seconds and reset the comm instructions in the PLC.

Regardless your PLC code should contain code that checks for comm loss and do whatever to re-establish communications. You should not need to stop the PLC program to do this.