V130 to communicate data to SCADA. Modbus TCP over Ethernet.

[Jesse]

We have a V130-J-TR6 with an ethernet card installed. I have followed all of the examples and youtube videos but I still can't seem to get our iFix software to communicate. We are able to ping the ip address successfully but we still have a communications failure.

I have attached my code. One thing that I found inconsistent about some example projects and youtube videos is that some run a "socket init" FB and some don't. I have tried both ways unsuccessfully.

All we want to get from the PLC to SCADA is the Filter level, Turbidity, and LOH. (MI 17, MI 27, and MI 37)

Any other suggestions to the code is acceptable as well.

Filter Level Display_V4_Comms.vlp

[DanT]

Hi Jesse;

 

I downloaded your program and have looked it over.

A few Comments:

   1   You have many nets that have multiple logical statements in them

                   Break them out into  individual nets,  Look at the STL  Quick view.

                  Unitronics ladder processing prefers 1 logical statement  to produce 1 finite output from the net, not many logical statements and a confused final output.

                    ( I have seen cases where multiple statements in the same net gave the WRONG output desired, breaking them out into individual nets cleared the problem)

                 Unitronics has no limits for the number of nets in a subroutine.

  2.  In the     !Home   Routine,    Break  up Net 1  into 2   separate nets

                                Store and MB 31 in one  Net

                                Com setup in another Net

3.   In  the       !Home Routine ,    Break up  Net 2  into 2 separate nets,   Place the     Modbus IP Scan     in its own net  BEFORE calling the Main Subroutine.

                The way you have it placed is that it will be processed AFTER the Main Subroutine has been processed.

 4.   In the    Admin Password    Subroutine   Break into 2 separate Nets                     Change the     --|  SB54 |----     to a      ---| P |---   Leading edge one shot pulse

5.   In the   Main Subroutine   -- Break all those subroutine calls in Net 1  into individual nets, they will still get called in sequence.

6.  Unitronics has defaults for setting up the Ethernet Sockets.  You can modify them as needed, or restate them in the net to avoid ambiguity ( I do this in my programs)

7.  If you want your SCADA to pick up specific data, and it is spread out over different  MI's,   regroup them together in 1 area to make the Modbus calls easier.

         ( if you cannot regroup them , then use a   STORE   to send them to a grouping area)

Doing these will help you troubleshoot your connection issues.

 

DanT

 

 

 

[Fernando Castro]

3 hours ago, Jesse said:

I have attached my code. One thing that I found inconsistent about some example projects and youtube videos is that some run a "socket init" FB and some don't. I have tried both ways unsuccessfully.

I think you need the socket Init.

I have multiple PLCS as Modbus TCP/IP Slaves. and I do the following

 

On power Up first I have an Init sub ruoutine wich looks like this

 

Initialization:

(There are more things but only this line is relevant to Network)

 

Then I do the Modbus IP config on power up too

 

 

I enable Modbus Scan after Modbus Config was executed.

 

 

 Ignore the MBs inbetween (MBs 80,81,82,84),  I have some logic just to do a network restart on a specific sequence of steps relevant to my application, but you wont need to do that

Quick note, In my experience some unitronics OS have bugs related to protocol communication, so you can try with an older version if still can not communicate.

in my case v570 an v700 works with 4.8.10,  but I dont know about other PLC models.

 

[Flex727]

@Fernando Castro, great response to the post. You appear to organize your setup the same way I do (which is clearly the best way 😉). However, I'm curious why you have an inverted contact for MB 84 in front of your SET coil for the same MB?

[Fernando Castro]

2 hours ago, Flex727 said:

@Fernando Castro, great response to the post. You appear to organize your setup the same way I do (which is clearly the best way 😉). However, I'm curious why you have an inverted contact for MB 84 in front of your SET coil for the same MB?

there is some logic involved in order t do a specific sequence later on the code. I am not sure why but for v700 I had this issue on wich the socket got locked?  and reconnecting did not work, needed to reset power wich was not a viable option process wise and I need to be able to restart the connection whitout stopping the process, long story short on this sequence MB80 could  be active for a couple of scans,  I usually use the sets with same contact negated, that way set will only be executed once, ant that once is when it was not set 🤷‍♂️. 

 I don't like to abuse with the use of set /resets but I want to be sure that the only way I am going to have that set being set is if it wasn't being set already. 

 

 

[Flex727]

2 hours ago, Fernando Castro said:

but I want to be sure that the only way I am going to have that set being set is if it wasn't being set already. 

But a SET Coil would do nothing if the bit was already set, no?

[Fernando Castro]

1 hour ago, Flex727 said:

But a SET Coil would do nothing if the bit was already set, no?

yes it will, its being used in the other part of the code that Is not shown, a pulsed button triggers the logic of the reconnection, and during that reconnection the program could complete a couple of scans, and then if that NC contact was not there it will proceed to start modbus scan right away, and I don't want that 

 

 

[Flex727]

Hmm, I must not understand something because I can't envision any situation where that inverted contact would have any effect. It certainly doesn't hurt anything, but just seems totally unnecessary to me.

As I see it, if MB 84 is off, then it will be turned on - with or without the inverted contact. If MB 84 is on, then MB 84 just stays on, with or without the inverted contact.

[Fernando Castro]

5 hours ago, Flex727 said:

Hmm, I must not understand something because I can't envision any situation where that inverted contact would have any effect. It certainly doesn't hurt anything, but just seems totally unnecessary to me.

As I see it, if MB 84 is off, then it will be turned on - with or without the inverted contact. If MB 84 is on, then MB 84 just stays on, with or without the inverted contact.

I guess you are right 🤔, but I swear there is a use case for something like this,.... after I looked into it again this is not. 

[Flex727]

I seriously thought I might be missing something important. Thanks for double checking.

[Jesse]

Fernando, I have tried the things you listed except for the older OS install. Still no luck. How exactly do you try an older OS?

[DanT]

Hi Jesse;

I looked at your program again and began to edit a few things.

You have the PLC name set as an Indirect address  MI  0    -- as set up   -- the name of the PLC is a NULL ( No Name)

You are trying to use a MI  Integer as the name, this will not work - I found the screen where you assign the PLC Name - COMMS

The name should be an ASCII   String, and if you tried to write a name here(MI 0), you will overwrite MI1,MI2, etc. or Invalid ACSII Characters

 Even if the Name is to be a number, the  number is entered as an ASCII String   --     Modify your COMM HMI Screen to enter the PLC Name 

Store the PLC Name some where else   - in your program I chose  MI 500 

Maybe for testing, enter a  the PLC Name as a Direct String      like  V130TR6

The PLC Name acts like a password to access the PLC

Look up    PLC Name     in Help

  Attached  are my revisions -- to the program --  my revisions are in   Startup Net  and  COMMS   HMI

 

Just as a note:      MI's  can be used to store and work with   Integer Numbers,  and also  store and work with ASCII Chars

                                      When you use MI's to store ACSII Chars, change the view from   DEC to HEX    and have an ACSII Table  handy 

 

DanT

622564519_FilterLevelDisplay_Dan0429A.vlp

[Ausman]

As an aside to perhaps help you understand what Dan is saying, please consider the following.  I have recently been writing elsewhere about using the RTC to ASCII function, but the way it works is similar.

This is the result in an MI vector of writing the date from the RTC using the function.

Note how I've got the data set to display as Hex, which is simply done by left click on the DEC/HEX description cell to alternate b/n the two.  The format is written as DD_MM_YY and in this case it is the 24th of April, 2022, so is 24_04_22 using our local naming convention.  Now consult the table.

If you look at Hx 32 you'll see that it is Chr 2, and Hx 34 is Chr 4.  Hex 5F is _ etc. so I'll let you figure out how things are in the MI as Hex to get the full display correct.

cheers, Aus

[Fernando Castro]

On 4/29/2022 at 9:16 AM, DanT said:

Hi Jesse;

I looked at your program again and began to edit a few things.

You have the PLC name set as an Indirect address  MI  0    -- as set up   -- the name of the PLC is a NULL ( No Name)

You are trying to use a MI  Integer as the name, this will not work - I found the screen where you assign the PLC Name - COMMS

The name should be an ASCII   String, and if you tried to write a name here(MI 0), you will overwrite MI1,MI2, etc. or Invalid ACSII Characters

 Even if the Name is to be a number, the  number is entered as an ASCII String   --     Modify your COMM HMI Screen to enter the PLC Name 

Store the PLC Name some where else   - in your program I chose  MI 500 

Maybe for testing, enter a  the PLC Name as a Direct String      like  V130TR6

The PLC Name acts like a password to access the PLC

Look up    PLC Name     in Help

  Attached  are my revisions -- to the program --  my revisions are in   Startup Net  and  COMMS   HMI

 

Just as a note:      MI's  can be used to store and work with   Integer Numbers,  and also  store and work with ASCII Chars

                                      When you use MI's to store ACSII Chars, change the view from   DEC to HEX    and have an ACSII Table  handy 

 

DanT

622564519_FilterLevelDisplay_Dan0429A.vlp 174.57 kB · 1 download

I dont think PLC name should be necessary  when trying to establish commuinaction over modbus TCP/IP but, sure the PLC name should be propperly assigned if you want to use other unitronics software that uses ethernet @Jesse you should check that too just to rule out that.

 

On 4/29/2022 at 6:57 AM, Jesse said:

Fernando, I have tried the things you listed except for the older OS install. Still no luck. How exactly do you try an older OS?

 

Check this post that from a couple of moths ago, someone had that problem and was the OS, over there is explained how to and wher to download the OS.

But before digging more deeply on Unitronics side problems, are you 100% thet the issue is not on the SCADA side, or the network itself?

do have any other way to test the modbus communication?

I use a CODESYS based virtual PLC on my computer  to thest ethernet based communications. I mean, sure it will require time to set it up an learn to use the plataform, but being free I feel is  worth it.

 

[Jesse]

Dan, Fernando thank you. I finally got the issue resolved.

After I fixed the "PLC Name", I also noticed the lower part of the "Modbus IP Config". Somehow I missed this part in the manual where you have to input the slave ID and address. I had seen this before but I thought that part was only if you were setting the PLC to be the modbus master.

We are going to have 12 of these on line connected to SCADA. 4 sets of 3 of them will be ran to a switch. Does it make since for each one of these to have all 12 lines filled out or do I only need a single line for that particular PLC? My thoughts were that they will all have seperate IP addresses (XXX.XXX.XXX.YY). Where the YY will be different for each and the slave ID will remain the same. The goal here is to use a single code for all 12 V130s then just changing the YY through the HMI. Is this going to be possible?

[Flex727]

1 hour ago, Jesse said:

I had seen this before but I thought that part was only if you were setting the PLC to be the modbus master.

This IS only if the PLC is the MODBUS Master. It does not need to be filled out when it is a MODBUS Slave. That was not your problem.

 

1 hour ago, Jesse said:

My thoughts were that they will all have seperate IP addresses (XXX.XXX.XXX.YY). Where the YY will be different for each and the slave ID will remain the same. The goal here is to use a single code for all 12 V130s then just changing the YY through the HMI. Is this going to be possible?

Yes, this is absolutely possible.

[Fernando Castro]

6 hours ago, Flex727 said:

This IS only if the PLC is the MODBUS Master. It does not need to be filled out when it is a MODBUS Slave. That was not your problem.

I was about to say the same,  slaves doesn't need to know other slaves or even the master IP, only the Master needs to know the IP addresses of each device it is going to connect with

 

8 hours ago, Jesse said:

We are going to have 12 of these on line connected to SCADA. 4 sets of 3 of them will be ran to a switch. Does it make since for each one of these to have all 12 lines filled out or do I only need a single line for that particular PLC? My thoughts were that they will all have seperate IP addresses (XXX.XXX.XXX.YY). Where the YY will be different for each and the slave ID will remain the same. The goal here is to use a single code for all 12 V130s then just changing the YY through the HMI. Is this going to be possible?

I have like 180 devices, and I set the IP and PLC name on a settings screen on each PLC.

So if at some point someone requires to change the IP, or use a different network you won't want to be required to download the program again.

at least thats my recommendation, I like to be able to leave work and not to be bothered just because some IP is already taken by another device  😂

As an engineer I knew used to say.  "And thats how its done... If you  want to go to bed early"