NWT.Stuff
I am  struggling to compile this Code.
MW-Control-Word.jpg 

I am writing successfully to my Modbus Control Word (MW0).  The Code works perfectly without Rung 2.

My question is am I addressing the MW correctly.  The following don't seem to work MW1.0, my_tag.0 etc.

It locks up here
Locks_Up_Here.jpg 

Am I missing a trick here with the IEC standard style code ?  I am more used to programming in RS-Logix or PL7.

P.S. I have also tried using a %MX1.0 style register instead of %IX...

Many Thanks in advance , Kevin
Quote 0 0
thiagoralves
You can’t use dot notation on variables. You only use dot notation on locations (ie %QX0.3). In any case, OpenPLC doesn’t use dot notation on anything that is not X (bit size), so word location are always %MW0, %MW1, etc. If you need to use a memory coil you can always use any %QX location that is not available on your physical hardware, like %QX20.0 for example
Quote 1 0
NWT.Stuff
OK Got it. Thanks for the help.  I think I am using the wrong modbus function and fc5 would be more suitable.
Quote 0 0
thiagoralves
Another solution would be to keep using %MW0 but then have a function block to separate all the bits for you. I'm pretty sure that OSCAT library has one block for this: https://openplc.discussion.community/post/oscat-basic-333-oscat-building-openplc-10284818?pid=1310418069
Quote 0 0
BenKissBox
Hi NWT,

there is also a specific thing to know about the dot notation. Chapter 6.5.5 of the IEC61131-3 norm says that dot notation is not defined by the norm, it is defined by the integrator (line 10 of table 16 in the norm and chapter 6.5.5.2) as a "hierarchical" addressing, without any details about what the hierarchy means.

The confusion comes from the fact that many IEC1131-3 implementations (including the OpenPLC one) use the dot notation to extract bits from a input byte/word and many IEC programmers assume this is applicable to every type of data.

In other terms, %MX1.0 can have a completely different meaning on two different platforms and may not even work on some platforms

Benoit
Quote 1 0
NWT.Stuff

Thanks for the explanation Benoit. 

It’s a while since I touched PLC code and it was probably RSLogix from memory. It just seemed intuitive to me.

As I have a miniscule amount of control functions I went with the luxurious solution of using an whole MW Word for each function 🙂

Kind Regards Kevin.


Quote 0 0
BenKissBox
NWT.Stuff wrote:

It’s a while since I touched PLC code and it was probably RSLogix from memory. It just seemed intuitive to me.



Hi Kevin,

Don't worry, I have exactly the same problem. I have written programs on a lot of different PLC (Schneider, Square D, Siemens, SMC, April, NUM, ALSPA, Allen Bradley, Alstom, etc...). There are features you see on different machines which appear as standard... but they are not 😈
And worse : something written with the same syntax may work in a complete different way on two machines...

To illustrate that, let me tell you the kind of crazy things I have seen : SMC was a french manufacturer of PLC (they became April before being absorbed by Schneider Electric). They implemented MODBUS in their PLC, but they changed the name to JBUS (no idea why)
JBUS and MODBUS are working exactly in the same way for all common functions... except one thing : in MODBUS, coils, inputs and registers are numbered from 0, but JBUS starts counting at 1 😜
The fun begins when you start to mix MODBUS and JBUS devices on the same network and want different PLC to talk to each other. The first time I worked on such a setup, it took me hours to understand why everything was shifted by one byte in my PLC memories.

Benoit
Quote 0 0
NWT.Stuff
it’d almost forgotten how much time one could lose trying to understand what’s going on inside those PLC’s. 🙂

I’m actually in the middle of a bit shift project. With Python I used 1 to 8. With OpenPLC it’s 0 to 7.  Now all I have to do is find all the places I have used the bits.  A bit of a chore but well worth the effort to get a free PLC platform 🙂
Quote 0 0