ratdude747

[SOLVED] Pro-Face GP4000 Series Ethernet/IP connection issues

20 posts in this topic

Having a bit of a headache trying to get a Pro-Face HMI (GP4000 series, a PFXGP4501TAD to be exact) to pull data from an AB Point I/O system (1734-AENT C, already upgraded to the latest 7.011 FW) and another ethernet/IP devices

The system I'm building has several Ethernet/IP connected devices (Oriental Motor AZD-AEP Stepper Controller, Keyence LS-9000 Optical Micrometer (with the ethernet/IP module added), and the aforementioned AB Point I/O setup); I'm using the HMI as the PLC. The motor controller hasn't come in yet, but I have been able to connected with my laptop and set IP addresses on the other two modules (including the ethernet programming interface of the Keyence system). I also was able to get on the Point I/O and set the rack size... and it's seeing all my inputs (was able to bench test such).

 

However, I'm having no luck communicating with anything via the HMI. Funny, AFAIK it's not throwing a fault for the missing motor controller, but the two devices I have are fault city. 

Questions: (I'm a bit of an EIP noob... most of my experience is with Mitsubishi, CC-link, and Pro-Face HMIs connected to Mitsubishi PLCs):

  1. What class should I be using for assemblies (assuming that's what to use here, as the manuals talk about assemblies, but never use the word class)? 4, which is labeled as "assembly" in GP-Pro?
  2. GP-Pro has me entering instances in Hex... but none of the manuals (Keyence, AB, or Oriental Motor) specify the the addresses in hex or dec (they always start at 100 it seems though). Is that "100" a hex value or a dec value (enter 64 for the actual starting address). 

I've only ever used Pro-Face on EIP for interfacing banner safety controllers to Mitsubishi PLCs (moving data in the ladder program)... but they're starting the addresses at 1, not "100", and apparently they're using a vendor defined class of 63. Seems to be a different setup? 

 

Attached are a few screenshots from the code and prints. I'd prefer not to discuss what this machine actually does (NDA), hence why I'm not attaching the full code and prints. . 

Screenshot 2022-03-14 191615.png

Screenshot 2022-03-14 191659.png

Screenshot 2022-03-14 191735.png

Screenshot 2022-03-14 191812.png

Screenshot 2022-03-14 191841.png

Screenshot 2022-03-14 192010.png

Screenshot 2022-03-14 192213.png

Screenshot 2022-03-14 192233.png

Edited by ratdude747

Share this post


Link to post
Share on other sites

Full disclosure:  I have zero experience with ProFace.  But I have a good bit of experience with EtherNet/IP.*

The key will be turning on "Rack Optimized" functionality in the 1734-AENT to use a single pair of buffers for the GPIO.  The 1734-AENT's EDS file should have the assembly numbers you need for that.  IIRC, the three assemblies' buffers (in, out, config) will be the concatenation of the sub-device buffers.

If that "indirect device" button lets you specify a slot number after the IP address, you can make separate I/O connections to the four GPIO modules instead of a single connection to the adapter.  Then the EDS files for those modules will contain the necessary assembly numbers and config content.  I always use the separate connections when the scanner supports it because rack mode breaks my brain. Unfortunately, not many scanners support slot addressing. /:

* Ethernet/IP Suite in the Ignition Module Showcase

Share this post


Link to post
Share on other sites

Per a re-read of the EDS file, it's showing the configuration assemblies as class 4 and the exclusive owner assemblies as being class 6? 

 

What I think is the relevant section of the EDS file (I'm a noob to EDS files too):

 

[Assembly]
        Object_Name = "Assembly Object";
        Object_Class_Code = 0x04;

        Assem9 =                        $ Output data format for non-Logix Rack
                "Assembly Config",
                ,                       $ no path specified
                10,                     $ number of bytes
                0x0000,                 $ descriptor
                ,,                      $ reserved
                32,1,                   $ CRN
                16,Param200,            $ Chassis size
                8,Param204,             $ T2O Alignment
                8,Param205,             $ T2O Size per slot
                8,Param206,             $ O2T Alignment
                8,Param207;             $ O2T Size per Slot


[Connection Manager]
        Object_Name = "Connection Manager Object";
        Object_Class_Code = 0x06;

        Connection1 =                   $ Exclusive Owner Assembly Connection
                0x04010002,             $ trigger & transport
                                        $   0-15  = supported transport classes (class 1)
                                        $   16    = cyclic (1 = supported)
                                        $   17    = change of state (0 = not supported)
                                        $   18    = on demand (0 = not supported)
                                        $   19-23 = reserved (must be zero)
                                        $   24-27 = exclusive owner
                                        $   28-30 = reserved (must be zero)
                                        $   31    = client 0 (don't care for classes 0 and 1)
                0x44640405,             $ point/multicast & priority & realtime format
                                        $   0     = O=>T fixed (1 = supported)
                                        $   1     = O=>T variable (0 = not supported)
                                        $   2     = T=>O fixed (1 = supported)
                                        $   3     = T=>O variable (0 = not supported)
                                        $   4-5   = obsolete - value not changed for backwards compatibility
                                        $   6-7   = obsolete - value not changed for backwards compatibility
                                        $   8-11  = O=>T header (4 byte run/idle)
                                        $   12-15 = T=>O header
                                        $   16-19 = O=>T multicast,point-to-point
                                        $   20-23 = T=>O multicast,point-to-point
                                        $   24-27 = O=>T scheduled
                                        $   28-31 = T=>O scheduled
                ,Param2,,               $ RPI, O=>T Size (sizes in bytes), format
                ,Param3,,               $ RPI, T=>O (sizes in bytes), format
                ,,                      $ config part 1 (private configuration)
                ,Assem9,                $ config part 2 (configuration)
                "Assembly Exclusive Owner",    $ connection name
                "",                     $ Help string
                "20 04 24 66 2C 64 2C 65";    $ Connection Points for Assembly cnxn

        Connection2 =                   $ Listen Only Assembly Connection
                0x01010002,             $ trigger & transport
                                        $   0-15  = supported transport classes (class 1)
                                        $   16    = cyclic (1 = supported)
                                        $   17    = change of state (0 = not supported)
                                        $   18    = on demand (0 = not supported)
                                        $   19-23 = reserved (must be zero)
                                        $   24-27 = exclusive owner
                                        $   28-30 = reserved (must be zero)
                                        $   31    = client 0 (don't care for classes 0 and 1)
                0x44240305,             $ point/multicast & priority & realtime format
                                        $   0     = O=>T fixed (1 = supported)
                                        $   1     = O=>T variable (0 = not supported)
                                        $   2     = T=>O fixed (1 = supported)
                                        $   3     = T=>O variable (0 = not supported)
                                        $   4-5   = obsolete - value not changed for backwards compatibility
                                        $   6-7   = obsolete - value not changed for backwards compatibility
                                        $   8-11  = O=>T header (heartbeat)
                                        $   12-15 = T=>O header
                                        $   16-19 = O=>T multicast,point-to-point
                                        $   20-23 = T=>O multicast,point-to-point
                                        $   24-27 = O=>T scheduled
                                        $   28-31 = T=>O scheduled
                ,Param2,,               $ RPI, O=>T Size (sizes in bytes), format
                ,Param3,,               $ RPI, T=>O (sizes in bytes), format
                ,,                      $ config part 1 (private configuration)
                ,Assem9,                $ config part 2 (configuration)
                "Assembly Listen-Only", $ connection name
                "",                     $ Help string
                "20 04 24 66 2C BF 2C 65";    $ Connection Points for Listen-Only cnxn

 

Share this post


Link to post
Share on other sites

No, they are all class #4.  What is label "Assem9" in the EDS file is really assembly (connection point) 0x66.  You must supply 10 bytes of configuration as shown in "Assem9".  I'm not sure of the units.  Should be part of the descriptions for EDS params 200, 204-207.

Share this post


Link to post
Share on other sites
3 hours ago, ratdude747 said:

"20 04 24 66 2C 64 2C 65"

FYI:  This reads "class 0x04, instance 0x66, connection pt 0x65, connection pt 0x64.

Applications paths for class 1 connections supply a config path, an output path, and in input path.  Abbreviation rules allow omitting class codes when they would repeat the previous.  Class 4 (assemblies) defines "connection pt" == "instance".  Class 4 also has an implicit attribute #3 for each instance when not specified.  Attribute #3 of assemblies is the I/O buffer itself--necessary when using class 3 messaging instead of I/O connections.

Share this post


Link to post
Share on other sites

The 10 bytes is the first big rung in the init program. 

I'm running a stripped down version of the program to try to eliminate variables. All it has in the init program is that one block (with nothing in the running ladder) and with no direct tags or data on the screens. As soon as it tries to run the init program on bootup it starts throwing read errors (which is odd, since all I'm doing is writing at this point).

I also tried setting up implicit communication (which I determined does use decimal addressing, no hex) to dump the config, in, and out to internal HMI registers... while that eliminated my errors, even with an RPI set to 30ms I'm getting no communication or data being imported to the registers. So I've abandoned that line of thinking, for now. 

Attached is that 10 byte bit of code. It's written as 5 2-byte words, which is 4 bytes of reserved area (write 0, I've tried eliminating these and didn't help), two bytes of rack size (5), and two sets of two bytes of slot alignment and byte size per slot (one for inputs, one for outputs).

 

 

Screenshot 2022-03-15 135212.png

Edited by ratdude747

Share this post


Link to post
Share on other sites

Seems the issue is that the point I/O controller isn't recognizing my HMI as the owner of the owned data. The Network status light is flashing green, indicating that it's connected to a network but no CIP connection has been initiated.

 

Is there an address/command I need to issue to establish a communications link? Or does accessing such parameters (or writing to any consumed data) establish ownership and a CIP connection?

 

Edit- This is the Forward_Open command... which the pro-face driver manual seems to imply is done automatically when using implicit messaging (only mentioned once, in the context of the configuration size setting for the implicit messaging option).  It's like the device isn't seeing the Forward_Open request. 

 

Edit2- when trying explicit messaging (the bit of code above), the error is 14h, 00h... which according to the attached manual indicates "attribute not supported". 

 

Edit3- Also having the above issue when trying to pull data from the Micrometer Com module... I tried both assemblies (class 4) and vendor defined "CB objects" (class 6B, also called out in it's EDS file). Entering obviously wrong attributes or classes changes the fault to "unknown address" (05 00)... which tells me I'm barking up the right tree, but for some reason the HMI (or everything else) is butting me out every time I try to read or write something explicitly?

odva_exp.pdf

Edited by ratdude747
More info. Calling it a night.

Share this post


Link to post
Share on other sites

You absolutely must use implicit for ownership.  The forward open request that establishes traffic must carry the 10 bytes of configuration.  The code would have no message instructions at all if the implicit connection is used.

Share this post


Link to post
Share on other sites

Sounds like I have some research to do tomorrow. Other than giving a size and location inside user memory (which coding such didn't seem to help), it doesn't give anything more "direct" on what the indirect config data is. I'll try again and see. And verify that the correct data is getting sent to the memory locations that supposedly set such per the device setup. 

Share this post


Link to post
Share on other sites

I have to admit that I'd do the comms research with my Ignition module, two hours at a time (the free trial mode).  Then try to figure how to get the ProFace to do the same thing.

Share this post


Link to post
Share on other sites

Found something. DUH. :disgust:

Turning on that first word's bit intiates implicit communication... and more faults. One for an Illegal response to initial communication command, and one for received for implicit open command returned an error (01h 127h). 

At least something is happening. 

Screenshot 2022-03-16 075419.png

Share this post


Link to post
Share on other sites

The PDF user manual for my module has a troubleshooting table that explains most of the possible forward open error codes.....

Share this post


Link to post
Share on other sites

Fiddled with it a bit. Now I'm getting an 01H error... connection failed. The extended code is 109h; but the pro-face manual says I need to refer to the ODVA manual for the device. And I'm having zero luck finding a manual from rockwell defining what such returned codes mean. 

Keep digging...

Screenshot 2022-03-16 083536.png

Share this post


Link to post
Share on other sites
31 minutes ago, ratdude747 said:

what such returned codes mean

Pssst!  See previous comment.  Follow link to my Ignition module.  Click on the "Documentation" link there.  Scroll to the end.

Share this post


Link to post
Share on other sites

^Thanks. Missed that. 

Seems to be an assembly sizing error... Hmm.

Funny enough I tried setting up the micrometer as an implicit as well... and it worked no problem (or at least I was able to turn on the control bit to start the connection, and it didn't give an error once I fixed a fat finger error or two). 

Keep trying things... Supposedly in the default config (and the config I'm writing) it's byte aligned... which should be 12 bytes produced (8 bytes of slot status plus 1 byte per 8 port card) and 6 consumed (4 bytes run/idle plus one per 8 point output card). 

 

Share this post


Link to post
Share on other sites

Seems that I got screwed by the EDS file import.

It was setting the T->O to 32 bit header mode... which was warned about in the rockwell assembly manual (see screenshot). So, drop the input to 2 bytes (and the config to 0, something in my current setup it doesn't like but the default should work for my needs). And we have communication!

 

But, by stripping off the 4 bits, that gives me no way to turn on the run/idle state. So, contrary to what the EDS file told GP pro to do, Output size needs to be 6 and T->O set to modeless.

Stll not seing any input data... but at least I am getting data, finally.  EDIT- Nah, that was a monitoring issue. I got data and output control. Yay!

Screenshot 2022-03-16 103339.png

Edited by ratdude747
1 person likes this

Share this post


Link to post
Share on other sites

Reviving this thread with a "new" issue (machine is still being bench tested due to missing parts).

Intermittently I'm having communication issues between the HMI and the Point I/O controller. When it happens, I get a flurry of illegal response errors/inplicit communication errors on the HMI side; on the Point/IO side I get flashing red on the Network Status, POINTBus Status, and all four I/O module statuses. But the controller isn't logging any dropped packets or the like (the webpage is indicating all is good). Communication re-establishes automatically within 60 seconds. 

 

Current settings:

  • Two of the three specified controllers are present (one isn't, but I have it's implicit communication blocked out; the HMI is still trying to initiate a TCP connection with it and throws appropriate minor faults).
  • Unplugging my laptop from the network doesn't help. 
  • All three devices are set to unicast (I'm on an unmanaged 10/100 switch). When I initially had this issue such corrected the problem. But I've added some more functions to the HMI code.
  • Point I/O RPI set to 100ms, the other two (one active) is set to 50ms.Changing the other two to 100ms didn't help. The 100ms setting is showing up on the Point I/O webserver.
  • QOS is disabled on the point I/O... not that enabling it helped.
  • The other device present (Keyence High-Speed Micrometer) is communicating just fine. Zero faults/issues. 
  • Cables: The connection between the Point I/O and the switch is a 1ft CAT5e patch cord (the switch is mounted next to it on the DIN rail)
  • Grounding: not fantastic (due to waiting on grounding terminals to come in). The panel is bonded to the 120V earth. And the Point I/O is bonded to the panel through it's DIN rail brushes. Currently the switch isn't bonded/grounded (but will be once I have the grounding terminals once they're in).
  • HMI: Don't know what the CPU load is, but based off the logic times (which I do have) and screen update times (also available), it should be keeping up. But if not, what's the RPI tolerance on the point I/O?
  • Point I/O firmware: Latest firmware (7.011) flashed. Haven't tried flashing older firmware yet. 
Edited by ratdude747
spelling

Share this post


Link to post
Share on other sites

Default for AB scanners has connection drop timeout at 4x the RPI.  Other scanners may make it configurable.  With that assumption, anything on the network that drops packets for 400ms will break the Point I/O connection.  Grounding would be a possible cause.

I recommend using a port mirroring managed switch that can feed wireshark/tshark in ring-buffer recording mode.  Examine the ring buffer after the next upset.

Share this post


Link to post
Share on other sites

A managed switch isn't in the cards, nor is something I happen to have at my disposal. I do suspect that CPU loading may be an issue as some occurrences have happened when I change screens and there is a lot of content to update. Looking to see if there is anything I can do to change priorities/reduce frame rate of the screens. 

 

Edit: I seem to have narrowed it down to one screen in particular... with a somewhat complex graph. Going to try to slim it down a bit to see if that helps my cause. 

Edited by ratdude747

Share this post


Link to post
Share on other sites
1 hour ago, ratdude747 said:

A managed switch isn't in the cards, nor is something I happen to have at my disposal

With the goal of placing wireshark/tshark where it can see the traffic, the simplest option is to add a USB ethernet device to your laptop and make a bridge.  HMI on one port, other port continues to the switch.  Since the HMI's packets then have to traverse the laptop, wireshark there can see them.

{ I don't recall the incantations required in Windows, but I do similar in Linux all the time. }

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now