Comm problem between RedLion G308A and MicroLogix

I've been trying for a while to communicate a G308A TouchScreen with a Micrologix1500.

I'm using a CBLGEN01 cable and a "homemade" female to female adapter...

I'm not sure how the PLC receives the inputs from the screen, is there any programming tip I'm missing when it comes to addressing inputs inside the RedLion programming software?

Thanks in advance!

I would advise mapping the real I/O to internal bits and addressing those bits.

I know there are some weird things about the expansion I/O addressing but I am whistle-bit, so I will have to let others chime in. Are you using Crimson 3?

Do you have your Comm's set up?

Did you setup the Micrologic 1500 in your Comunication Setup inside the Red Lion?

@OkiePC: No, I'm using Crimson 2.0, you think that might be causing any problem?

@Clay B.: I think so, I'll try to upload images of the setup tomorrow morning at the office.

mmarinr said:

@OkiePC: No, I'm using Crimson 2.0, you think that might be causing any problem?

Click to expand...

No, I don't think it's a problem to use 2.0

I am more familiar with 3.0, but I think the driver set up is very similar.

I recall a thread a few weeks back about the way the addressing for expansion I/O appears in RSLogix does not match up with the way it is addressed for a Panelview (which would also apply for any other HMI).

The base I/O should appear normally. I still recommend mapping the I/O in the PLC to internal bits and use those for display purposes. This will let you avoid the addressing issues, allow you to make changes without having to redo the HMI program, and avoid inadvertently writing to outputs with the HMI.

I think the driver you'll want is "Allen Bradley DF1 Master" and the baud rate must match that of the Micrologix. If you're using DH485, then you'll want to choose the "Allen Bradley DH485 Master".

To test comms, you can use the function in the G3 called IsDeviceOnline where n is the device number that will appear for that particular channel.

I normally create a flag tag called STATUS_COMMS and assign it to complex code in which I put "return IsDeviceOnline;". Then I assign an Alarm to that tag set "active off", "level triggered". This way I get an alarm when comms fail.

Another way to test is to put a tag like "B3:0/0" or "N7:0" on a display page and see if it populates or shows "---".

With serial drivers and a G3, if your cable is right, comms will start working within a couple of seconds after you connect, and will stop working within a couple of seconds after you disconnect. Their drivers are very good at detecting comms status and displaying the tags, or not displaying them.

mmarinr,

OkiePC is offering good advice and yes this will work just fine with C2. Assuming your port settings in Crimson match up with your conifguration in the PLC I would look at the cable.

I assume you are connecting to the DB9 port on the Micro by your previous description. If so you can follow the diagram for our CBLAB001 cable (http://www.redlion.net/Support/Cable/CBLAB001.pdf)

Thanks
Jeremy

I just checked the cable and there was a problem with it, CBLGEN01 can't be used to communicate HMIs with PLCs. So I went on and changed the connection on the pins and it appears that the PLC is sending data to the HMI cause I can see an alarm activated.

The thing is I still can't activate inputs inside the PLC from the HMI.

@OkiePC: I got a ladder used to take inputs and turn them into integers.

For example:

I:0 N9:0

|---||---------------------------( )---|

0 0

Is that what you meant when you told me to map the I/O in the PLC to internal bits??

Thank you all for the help!

mmarinr said:

The thing is I still can't activate inputs inside the PLC from the HMI.

Click to expand...

That's because the real input point is going to overwrite the status of that bit address before every PLC scan! You cannot write to inputs with the HMI that are physically connected to an input point on the PLC!

If you meant to say outputs, then, first, I would advise against doing that! (What if the cable fails or the G3 dies after turning on a critical motor?). Second, the PLC can't have an OTE instruction for the same output address or there will be a battle to control the state.

mmarinr said:

@OkiePC: I got a ladder used to take inputs and turn them into integers.

For example:

Code:

   I:0                          N9:0
|---||---------------------------( )---|
    0                              0

Is that what you meant when you told me to map the I/O in the PLC to internal bits??

Click to expand...

Yes. Then, in the G3 add a tag pointing to N9:0/0 to view the status of I:0/0 on the HMI. You can do the same thing for your outputs.

OkiePC said:

If you meant to say outputs, then, first, I would advise against doing that! (What if the cable fails or the G3 dies after turning on a critical motor?). Second, the PLC can't have an OTE instruction for the same output address or there will be a battle to control the state.

Click to expand...

I did meant outputs!

About the security issues, we've taken care of that, the PLC programming includes lots of restrictions to avoid those kinds of problems, so don't worry but thanks for your concern.

Now, I also have a ladder with integers that would turn on the actual outputs of the PLC. So the HMI has tags pointing to those integers.