ratdude747

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): 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? 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. . 

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. 

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. 

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!

^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).   

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...

Found something. DUH.  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. 

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. 

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

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).    

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  

A series CC-Link is "weird"... due to being developed after A-series itself had long been on the market, the programming of such isn't nearly as streamlined as on Q&L series. You'll want the GxConfigurator-CC program... a separate purchase from GxDeveloper (wasn't awfully expensive if I recall), but well worth it for working with A-series CC-Link (or QnA or the like). It does have network monitors and the like built in, although I haven't used them much personally. Side note: The main "perk" of the program is being able to create and write master module configurations, save them in a graphical format, and being able to burn them to buffer memory or EEPROM without the "original" method of programming a bunch of registers in the running PLC program. You'll still have to read/write directly from/to buffer memory and manually start the card and enable output updates, but otherwise, the program takes away a lot of the hassle with making CC-link work on A-series.   

Yep. M9006. I work with a lot of A-series based equipment... Usually Fault #1 tracks such... but that's because the same shop programmed and wired almost all of it (Narumi Denki of Japan) and it's all more-or-less cookie cutter methodology. Which isn't a bad thing, really. 

Maybe I had the wrong error number... I do know I was getting an error after formatting and rebooting.  Set in the PLC parameters, of course "built in ethernet port setting". Do know that a second Q03UDE CPU (for an identical robot cell) accepted the programming without an issue and works as intended. Looking like this CPU is faulty... 

Bought a couple of used Q03UDE CPUs on eBay for a project at work. One of them works fine, no issues. However, the other's IP address is stuck on 10.1.1.101 despite having the new address in the parameters (which comes back correctly when I read back the PLC parameters).  I've unplugged the backup battery (which isn't throwing the battery low bit) for a weekend to see if that helped... nothing Otherwise, the only other issues I had were with trying to set up file registers (kept complaining about being out of space despite setting the number of points really low) which I worked around by converting the code to using latched D-registers instead. I didn't test this on the other CPU, so it might not be related. I'm running the exact same code on both PLCs Is there some secret to fixing this CPU, or is it a dud? Thankfully I got them for very, very cheap so I (well, my employer) isn't out a whole lot if it's toast.   I've attached a copy of the code with the programs and comments removed (proprietary programming, sorry!) for those who want a peek. None of the file register parameters are set.  Q03UDE Paramter sample.gxw

No memory card. I did indeed get a 2400 error after formatting and rebooting. 

Will try... I did that several times while troubleshooting the file register issue, but not since pulling the battery for a weekend. Edit- No bueno. Even loaded a blank program which contained the default IP... didn't change at all. Formatted, cleared, and arranged memory.