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.

 

Perhaps, when the frame is into the serial driver, it's too late for the cancel EF or the cancel bit to remove the frame safely.

Meanwhile, you know when the frame is completely ended with the activity bit. Then you can send a write to all slave in broadcast to inform them you want to switch. And finally switch when the broadcast is ended.

For me, the cancel bit or the cancel EF are working only when frames are not yet arrived into the serial driver. It can happened if you use simultaneously several EF onto the channel.
In this case be aware that the EF timeout must be increased and you must not use the same management word.

 

Hi Sophie,

Thanks for your thoughts on this issue.
One of Schneider's local engineers here in Australia has said he'll watch for any further communications from the hardware designers regarding this problem.

You may be correct; perhaps it's too late to cancel the communications once the serial port has been sent the frame. But so far, the Schneider engineer hasn't drew my attention to that possibility.

But still, I appreciate your time.

Kind regards,
Roger Valmadre

 

Hi,
For those of you who are still interested in this thread, I recently had a communication with Schneider-Electric about this problem, and they came back with the answer that I can summarise (and paraphrase) as follows:

"Yes, we know that the cancel function doesn't kill a transmission while it's happening, and that the retry delay and number of retries can't be adjusted if a serial port is dynamically swapped from slave to master, and we know these things might be a problem for some people. With Unity 4.1 we will enable the programmer to adjust the retry delay and the number of retries."

This modification is a great improvement, even if it isn't quite the fix I was hoping for. (I was hoping that "Cancel" really meant "Cancel", but hopefully they might fix that, too.) If I hear of anything else, I might post it here for interest's sake.

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

Here's the original text of their response:
"We understand what customer is faced to in his application.
But the M340 serial port is working as following:
When a Cancel function is called, the answer of the communication EF (Read or Write_Var) will not be taking into account and the activity bit is reset, but all retries or frame sent will be executed. So the 3 retries will always be sent on the line even a Cancel function is called.

It could be a problem, so an improvment of the modbus master parameters while a switch slave/master will be available with the new M340 PLC firmware, commercialized with the next Unity Pro version V4.1 planned for the en of April 2009.

In this version, customer could modified the modbus master default parameters before a switch slave/master:
Answer Delay and Number of Retries.
A documentation will be included in Unity Pro V4.1 to describes this improvment."

 

Hallo my friend! I wonder whether you found a solution to your problem?

You know, I've made a connection like yours (two modicon M340 plc's communicating each other with modbus read_var etc) but I don't ever cancel modbus master with cancel bit or with some other way. I have no problem till now.

If i don't ever cancel the read_var but always read_var asks from slaves, do you think that if a slave has some problem replying? I will also have a problem with my master and communication will stop for ever? Have you had such a problem? Now you made me wonder!!!!