Hello dear members.

I have a question:

I'm working on an integration of a Siemens TP700 comfort operator panel to an old Allen Bradley Micrologix 1500 PLC. I managed to connect the HMI to PLC and exchange data, but I firts tried to read I/O at bit level and for some reason it doesn't work if I do it like that.

If I try to light some indicators reading I:0/0 doesn't work, I had to move the input words values to some integers file (N7) and then read the integers and select the bits. The HMI works that way but I'm curious if I did something wrong or if it can't read bit by bit in the case of I/O, because merkers work good (B3 file).

Could you explain me if you know something about this? Or share a example if possible?

Thanks in advance.

Regards.

Hope this helps:

Check the properties of the HMI Tag. This was in the DF1 protocol:

Hello, thanks for the help.

I got the next doubt, to declare a boolean input tag, would it be like:

I1:0/0?

I don't know much about this old AB PLCs, but I see that the input signals are on a "I1" named file on the PLC program.

regards.

Hello Rescobedo,

I had this problem, too, with a new PLC model of AB and a TP Comfort. We had only a few bits so we created one "FB" for writing status bits to a word and another one for separating a command word to bits. On the HMI we accessed then the single bits of those words.

Regards,

Frink

Hello.

My experience with ML1x00 PLCs with a non-AllenBradley (but not Siemens) ->

The AllenBradley is sneaky in this way:
The bit field (example: file B3) uses optimized packing. That means that the actual bits that exists are the ones you use in your program. (technical opinion based on observation; may be incorrect)

Lets assume B3:0/0 and B3:0/2 is called in the program - then then B3:0/1 gap causes an issue. If the gap is filled (by call in the program) then you are okay.

Be careful. The integers (example: file N7) has the same risk. Do not leave gaps - that is tags that are not called in the program.

Reading / writing a bit in the integer is good enough.

Inputs are formally known to be file I1 (india one), just like O0 (oscar zero) is for outputs. Perhaps The panel needs that full description.. I do not know. Looking at the interface I would expect the file number.

With some ML1500 I had enough outputs that was not actually linked to actual physical outputs. These outputs I used for bit lamps. Different than the bit field files, every output bit that you can read in file O0 (oscar zero), exists and is addressable. No gap filling required.

Some more background:
https://www.myplctraining.com/rslogix-500-addressing-tutorial/

I trust these tips are helpful.

Forgot to mention.. do remember that the ML1500 is WORD orientated, not BYTE orientated like the Siemens PLCs.

#dP

Hello.

My experience with ML1x00 PLCs with a non-AllenBradley (but not Siemens) ->

The AllenBradley is sneaky in this way:
The bit field (example: file B3) uses optimized packing. That means that the actual bits that exists are the ones you use in your program. (technical opinion based on observation; may be incorrect)

Lets assume B3:0/0 and B3:0/2 is called in the program - then then B3:0/1 gap causes an issue. If the gap is filled (by call in the program) then you are okay.

Be careful. The integers (example: file N7) has the same risk. Do not leave gaps - that is tags that are not called in the program.

Reading / writing a bit in the integer is good enough.

Inputs are formally known to be file I1 (india one), just like O0 (oscar zero) is for outputs. Perhaps The panel needs that full description.. I do not know. Looking at the interface I would expect the file number.

With some ML1500 I had enough outputs that was not actually linked to actual physical outputs. These outputs I used for bit lamps. Different than the bit field files, every output bit that you can read in file O0 (oscar zero), exists and is addressable. No gap filling required.

Some more background:
https://www.myplctraining.com/rslogix-500-addressing-tutorial/

I trust these tips are helpful.

Forgot to mention.. do remember that the ML1500 is WORD orientated, not BYTE orientated like the Siemens PLCs.

And after some checking - WinCC does not allow to create a tag with inputs or outputs addresses beyond 16 (0-15) for the same slot. So where you have 24 inputs on the ML1500 for example - you will not be able to have the HMI read 16 of 24 of those directly. This also negates my output usage tip.

 Thank you so much, this is what i needed to know, really helpful.

Regards.

Prof. Frink

Hello Rescobedo,

I had this problem, too, with a new PLC model of AB and a TP Comfort. We had only a few bits so we created one "FB" for writing status bits to a word and another one for separating a command word to bits. On the HMI we accessed then the single bits of those words.

Regards,

Frink

 Hello Profesor, yes, I took the same approach as you did and its working, I just wanted to know if here would be a way to do it without having to write code on the AB PLC.

Thank, regards.

Hi, I am interested in knowing how you managed to make the physical connection, ch1 configuration and cable pinout, thank you.