I/O Comm. problem btw PLC & HMI

WFox

Member
Join Date
Jun 2002
Posts
3
Hello, I'm new to PLC programming and recently hit an I/O comm snag.

I'm using a DirectLogic 205 DL250 PLC with an InTouch 7.1 HMI. The I/O Server is Modbus. When the HMI is reading data from the PLC, everything is fine. I can also write data to V-memory (I use DirectSOFT to double check), so no problem there. But when I try to write data to the control relays, things get weird.

Here's what happens: I use a user input touch link in the HMI to turn on a CR tag, and the CR in the PLC does turn on like it's supposed to. I can see in DirectSOFT that the CR goes from OFF to ON and stays ON. But in the HMI, the CR tag goes from OFF to ON for a split second, then goes back to OFF. For some reason, after writing to the PLC, the HMI is not reading (or incorrectly reading) the status of that CR bit from the PLC.

When I disconnect the HMI from the PLC and repeat the process (to troubleshoot), the CR tag in the HMI stays ON, instead of going OFF like it did earlier. So is there a problem with the PLC? What can it be?

Any reply would be appreciated.

- Wing Fox
 
I don't think there is anything wrong in either the PLC or the Intouch application. I think that maybe Intouch is executing one last 'Read' command before executing the 'Write' to the CR address.

You can try reducing the update frequency for the tags. There might also be an option called 'Read after Write', or 'Confirm Write', or something similar that you can apply to the tags.
 
I don't think there is anything wrong in either the PLC or the Intouch application. I think that maybe Intouch is executing one last 'Read' command before executing the 'Write' to the CR address.

I doubt it's because of the last read command because my HMI is not doing any reading of CRs at all, not even the ones I don't write to. I can read timer bits, vmemory, x, y, just not CRs.

However, I can write to CRs. Anyone ever had this problem before?

You can try reducing the update frequency for the tags. There might also be an option called 'Read after Write', or 'Confirm Write', or something similar that you can apply to the tags.

Where are these options that you speak of? I'm not too familiar with InTouch yet and I can't find them.
 
I haven't done Intouch personally for a long time, and I was never an expert. However, your post tickled a couple of long lost beer soaked memory cells from an application with Intouch and the DL-250.

First, I think when you set up your tags for indicators, you have to make sure they are set to both read and write the register. Otherwise, the tag can be read only or write only. Check your documentation.

Second, it seems to me that when we did Modbus with Intouch we had to read entire words, and then bit strip. This required, if memory serves me right, some extra ladder logic in the PLC to copy the CR words to V-registers so the Intouch Modbus driver could work with them.

Have you contacted tech support at Wonderware or at AutomationDirect.com? This is probably a common problem. If you solve it, please let us know how.
 
Finally figured out the problem. It was Modbus. It can only be configured (in the Topic Definition) to read I/O blocks of a certain size. In my case, it was a maximum of 2000 Coil Read and 800 Coil Write. I'm still not too clear exactly what those numbers mean. Basically, I went over my limit.

Since I was working with control relays and output relays, the block of I/O coils Modbus had to handle went beyond the max range. It really shouldn't have, but it did. Only after I took out the output relay tags could I read all the control relays.

As for transfering bits in registers (which would be perfect in this case), I actually did that in my PLC program, but found those bits way too tedious to read. It was hard to keep track of which bit is where, and towards which direction (MSB or LSB) the I/O server was reading to, so I gave up. How lazy of me ^^; I guess I should give it another try sometime, or just use a more flexible I/O server.

Anyway, much thanks to all those who tried to help. I really appreciate it. Since I'm still learning, this probably won't be the last time I ask for help here.

- Wing Fox
 
There are a couple of points about the RTU (Modbus) protocol that may shed some light on what you experienced.

First, the protocol allows you to read from and write to three distinct memory areas, Discrete inputs (1xxxx), Discrete outputs(0xxxx), and Data registers(3xxxx or 4xxxx). Its up to the implementation of the protocol in the DL205 to define which points are mapped to which memory types. Thus, X0 in the DL205 most likely corresponds to 10000, Y0 most likely corresponds to 00000, V0 most likely corresponds to 40000. In order to allow reading and writing of CR bits, they must be mapped to a specific modbus address in the 0xxxx range. The only place you're going to find that information is in the DL205 documentation, since the Modbus driver in Intouch doesn't know that it's talking to a DL205.

Second point. The minimum unit of data transfer in any Modbus transaction is one byte (8 bits). So if you ask to read a single bit such a Y5, you're going to get Y0 through Y7 whether you want it or not. It will be up to the implementation of Modbus in Intouch to sort this out. This adds a bit of complexity when you try to write a one or zero to a single bit in the PLC, because you need to make sure that the other seven bits in the byte are unchanged. The solution is for Intouch to first read the target byte, set or clear the specified bit, and then write the entire byte back to the PLC.

I hope this clarifies things rather than adding to the confusion.
 
Amazing how long I have been looking for this information.

I suspected something like this was going on. I had this problem with a DL250 I use and with a DL05 I am using now.

I'll copy the data from V40602 to something more reasonable (for modbus).

Thank you much all for the good information. Helped me piece together what I thought was going on and flesh out how I understand it!!

Garrett
 
Got it working...man what a giant pain...tons of screwing around with InTouch just to get it to work...AutomationDirect.com really needs to do something about that. Like make a cheatsheet on their website...

Basically, what I did was copy the control registers memory map location (VC40) to V2000, and then back again, except that it first reads V2000 to VC40 (so that the initial scan doesn't override InTouch (and therefor the operator)). I set this to SP1 so that this would happen each scan.

Then...the hard part...

Looking at http://support.automationdirect.com/docs/InTouchTechNote.pdf, the DL05 manual and calling on what little I already know of InTouch and these PLC's, I made an object that toggles the value of V2000 between 0 and 256 (which sets and clears C50). Except that with all the coversions from hex and octal and decimal, this is what I ended up with :

TagnameReadV2000.08 - the .08 part at the end specified that I wanted to change the status of C50 to ON. What it does is write a value of 256 (or 100, depending on the number format, I can't keep this stuff straight in my noggin) out to the PLC.

To clear the status of C50, I write a value of 0 to TagnameReadV2000. This I believe clears the entire group, but I am not using the PLC for much and this doesn't hurt my application.

Insto-Presto, the proverbial virtual switch. I used this method of using one tag for both reading the status and clearing it so that I would only use one tag : the license is a small old $600 jobber and it is stretched to the limit. NFW I am asking anyone to pay a couple grand for a few more tagnames... You could use one tag to write and one tag to clear, might be a little simpler than trying to determine which number is mapped to which contact...I dunno, maybe not, you're gonna have to make some design choices.

No thanks to AutomationDirect or WonderWare for making this process so difficult...I mean, its a discrete object. Item name 3113 for C50, On or Off...should be super simple. Writing was easy...reading it so very hard...

InTouch is so flexible, there are a lot of different ways to create your toggle object. I'd suggest touch pushbutton action to write the values that you are looking for instead of using the tagname.fields. It is just what I happened to use. Using the touch pushbutton action allows integers to appear to be a discrete operation...you could turn on any number of contacts seperately, but you could only clear them en masse (AFAIK so far).

Maybe I'll have to submit this to AutomationDirect for addition to their website...maybe they'll cut me a discount on my next order or something...

EDIT : To figure out the Cxxx value, what a pain indeed! Take your Vxxxxx address (say V40602 for the bank where C50 is stored). C40 starts this bank. Its value is 1. C41 follows at 2, C42 4, C43 8, C44 16, C45 32, C46 64, C47 128, C48 512, C49 1024...bleh... These decimal numbers become octal numbers, that when entered into the VC40 memory register, determine which combination outputs are on. The above numbers describe single outputs per bank...I can see why you would have a problem with multiple contacts being on at a given time...and why modbus isn't going to cut it for being easy to control these contacts with...at least AutomationDirect did give us 777 of them to play with, 32 of them seperate.
So where is the formula for doing this complex calculation on the fly from within an InTouch application script? ;)

G
 
Last edited:

Similar Topics

Hi, I am trying to do a very simple program to communicate the PLC with Hyperterminal. I am using a new CP1W-CIF01 Optional Board (RS232) with...
Replies
4
Views
2,487
Looking for anybody that has experience using the older PV550 displays. Have a locked up comm port. Is there any hard factory reset procedure...
Replies
3
Views
1,350
Hello everyone , I have an engineering station with step7 program. I can make the modifications from this PC for 7 PLCs. But now I can not...
Replies
5
Views
1,880
Hi, First post, I am new to this forum. I tried searching with no luck. I am using an Omron PLC - CJ2M CPU32,and I am trying to get it to...
Replies
0
Views
2,385
I am trying to program a stubborn PV600 and having comm problems. Once source says I need a 2711-NC13 cable with just 2-2,3-3, and 5-5. Another...
Replies
1
Views
1,197
Back
Top Bottom