CLICK (Koyo) PLC - Modbus Read - Problem

[dpslusser]

Hey guys,

I have one of the new CLICK plc from AD with an ethernet port on it.

I made a subroutine for an IO Map of a modbus slave device I have connected on the same network. All the sub is, is a bunch of read commands to put the values into Int registers of the CLICK PLC. My problem is that the sub routine will only scan the first line of code. It won't scan the next line of code.

I know its not a problem with the slave device becasue I also am using Kepware to double check my slave and I can see all the values of the registers no problem.

PLCTALK.net wouldn't let me upload the file (maybe I was doing it wrong) so below is the dropbox link to the file:

https://www.dropbox.com/s/2kuciy5yq7ckexn/Ethernet_IP.ckp?dl=0

 

[bernie_carlton]

Generally zip anything before attempting to upload it.

Warning - I haven't done this but from experience with other communication instructions.

Use the 'status' flags of the read commands. Especially the 'Success' flag. Assign each to a different bit 'C' register. Use that bit to trigger the next read in line.

(Example) Use NOT C0 in line with the first read. Use C0 as the first instruction's 'Success' bit. Then use C0 to trigger the next command. Use C1 as it's 'Success' bit and so on.

When the 'Success' bit from the last instruction turns on (or on 'First Scan' - SC2) reset ALL of these bits. That should re-trigger the whole set.

You may wish to look at using the 'Error' flag also if needed.

 

[kwade]

What Bernie said and: Is there a reason the ONE READ instruction cannot work?
Your registers are contiguous, so change the first Receive to have Number of Master Addresses [ 6 ]


One big issue with existing code is that the successive Receive instructions are ALL triggered by Port_1_Ready_Flag

 

[dpslusser]

What Bernie said and: Is there a reason the ONE READ instruction cannot work?
Your registers are contiguous, so change the first Receive to have Number of Master Addresses [ 6 ]


One big issue with existing code is that the successive Receive instructions are ALL triggered by Port_1_Ready_Flag

That did work. Thank you.

But what do I do when there not contiguous. Like reading 00001 or 10001, etc.

I tried what Bernie said, but it didn't work right. On the other hand....it was late and I only had one eye open. I'll try it again and variations like it.

 

[OkiePC]

But what do I do when there not contiguous. Like reading 00001 or 10001, etc.

Make them so if possible. Copy data to contiguous spaces in the available memory. If there is a good reason you can't do that, then resort to multiple message instructions, but do interlock them.

One example where you may need to NOT read a copy is looking at system bits, like PLC Mode. If the PLC is stopped and it is critical that you read that properly, you can't rely on the stopped PLC to move that information to a more message friendly location.

 

[kwade]

That did work. Thank you.

But what do I do when there not contiguous. Like reading 00001 or 10001, etc.

Non-contiguous: If the gaps are small AND the range is within limits, read the range. Ignore the unnecessary registers.
Eg. Need 00001 - 00005, 00009 - 00015:
Read 00001 with a count of 15, ignoring 00007-00008.
The data space required for the unneeded registers may very well be less of a consideration than the overhead of a separate Receive. You'll find that industrial equipment does this to optimize reads. (See AD forum post )

If you need to skip a large range:
Eg. Need 00001 - 00004, 00150 - 00151:
Yeah, I would recommend two receives. As Bernie said, use the 'Success' of the first receive to enable the second receive.
Be sure to have other controls in place to the ReadEna the instructions.

    ReadEna    Succ1
-----] [--------]\[--------------+ Receive +
                                 |         |
                                 |         +-() Recv1
                                 |         |
                                 |DS1      +-() Succ1
                                 |RegCt=4  |
                                 |         +-() Err1
                                 |         |
                                 +---------+

    ReadEna    Succ1    Succ2
-----] [--------] [------]\[-----+ Receive +
                                 |         |
                                 |         +-() Recv2
                                 |         |
   Note: Leave enough room here> |DS5      +-() Succ2
         For future reads        |RegCt=2  |
                                 |         +-() Err2
                                 |         |
                                 +---------+

Again: As Bernie mentioned, after a cycle of reads, be sure to RESET the success status to allow another read cycle.

 

[dpslusser]

Kwade,

I tried a variation similar to what you had drawn. But something still wasn't letting the Read function move to the next rung. I really wish I had the ability to trend the "Success" bit similar to trending bits in AB. Man that is a life saver.

So, Im not sure if its latency in the slave device, or the speed of the master device.

The simplest way I was able to get it to work:

Build a free running timer at the top with a counter. The read function is only true when the counter equals its assigned number.

So, in conclusion, thanks for all the help and ideas. This project was trying to figure out the simplest way to implement. The Master Addresses helped alot and will save space/time.

 

[kwade]

Zip it, post it.
We'll look at it.

Anyway, glad you are moving along.

 

[dpslusser]

Zipped it and shipped it

 

[bernie_carlton]

That's just a timer and counter. ????
Edit - sorry, didn't scroll down through the NOPs

 

[dpslusser]

That's just a timer and counter. ????
Edit - sorry, didn't scroll down through the NOPs

No problem.

The new problem I am having is when I add a another read function for a different device. IP address 192.168.10.92. It won't read the tags from that device. Do I have to close the connection with .91 in order to open .92????

 

[kwade]

No problem.

The new problem I am having is when I add a another read function for a different device. IP address 192.168.10.92. It won't read the tags from that device. Do I have to close the connection with .91 in order to open .92????

One thing from the latest post, you should consider using the status bits (outputs) of the read instructions.

Look at the AD website for the Tech Support link in the BLUE BAR.
Go to Example Programs. Find the Communications section.
Download the CLICK to SR55 example.
It may help you a lot.

This is the link, but thought that you might like to see the other example programs.

http://support.automationdirect.com/examples/CLICK/EP-COM-027_CLICK.zip

k