Control.com - Nerds in Control

I've been working on a Modicon M340 project using a CPU BMX P34 2020 processor, making use of its serial port to do Modbus master communication with a Modbus slave PLC, a Modicon Compact 984, connected via a radio link. Each of these PLCs control it's own sugarcane railway locomotive, and they can operate as master or slave. (I should acknowledge that I had a well designed program from the original 984 PLC to base my M340 program on, thankfully.)

Well, the communication seems to go very well indeed, using Read_Var and Write_Var blocks in a FBD program in the M340. (That's once I'd worked out _exactly_ how to use Unity's powerful functions.) But when I try to cancel a communication using the Cancel function, (during testing, I'd disable the slave so it couldn't reply, to see what happened) it seems as if the M340 PLC ignores the Cancel function, and just keeps on with the three retries and three second timeouts.

I call the Cancel function while the Read_Var or Write_Var function is still active, and use the current communications number, and there appear to be no errors from the Cancel function, so why doesn't the Cancel function work?

Hoping I'm not the first who's had this problem,

Kind regards,
Roger Valmadre.

Further to my last post, I'm aware that there's a "cancel bit" I can use when calling the "read_var" or write_var functions in the M340. I've tried using this "cancel bit" and that doesn't seem to cancel the communications, either.

Kind regards,
Roger Valmadre
rvalmadre@_removethisbit_csr.com.au

I have the same problem with a 340 and an Integra 1630 power meter....

Did you find something for the problem already?

Hi,
Sorry for the lateness of this post, but I haven't looked at this thread for a couple of weeks. :-(

Unfortunately, I haven't found a solution to this comms problem. I have contacted Schneider Electric Australia, and got feedback from one of their engineers; however, his response was basically that he didn't understand why it was happening, either. He and I both agreed that it _may_ be a firmware bug in the 340, and hopefully Schneider would release an update to it eventually. (Schneider is usually pretty good for this.)

If you (or anyone else reading this) find anything, feel free to email me at
rvalmadre@PLEASE_REMOVE_CAPITALS_csr.com.au

Kind regards,
Roger Valmadre.

Schneider have just released Unity V4.0 and V2.0 firmware for the M340. Various bug fixes in this.
The worked example for the Cancel command in the Help files is close enough. Key is to get the correct sequence number. Also note in some comms, your command is completed quite quickly so think about error handling using the comms report and either disable comms to the device or put it on a slow poll like the Magelis panels do that allows an auto restart to the comms when the device is available. If you are concerned about retries, etc., change the port settings.

Thanks, Alastair,
I knew that Schneider would eventually release a firmware update.

I've also carefully noted your other comments with regard to sequence number and retries.

As far as I (or the helpful Schneider engineer) knew, my programming was using the correct sequence number to attempt the cancellation.

As for retries, they seem to be fixed at 3 when the port is dynamically switched to "master" mode, which is how I'm trying to use it. (Of course, we could use seperate communications ports for master mode and slave mode, but that involves other hardware, and we were hoping to avoid that, as it means there's something else in the system which can fail.)

Anyway, thanks for your comments, and the news on firmware updates.

Kind regards,
Roger Valmadre.