pturmel

Please don't double-post.  Follow-up post is here: https://forums.mrplc.com/index.php?/topic/43695-got-simple-series-having-screen-error/  

In the PLC, use GSV to extract the EntryStatus, FaultCode, and FaultInformation into local variables.  Set the local variables to display in Hex format for best results.  In my EtherNet/IP module for Ignition, I format errors the same way, and document the most common codes in my user manual's troubleshooting section.  EntryStatus is purely a Logix creation, which I've tweaked for my own purposes, but FaultCode and FaultInformation are drawn directly from the EtherNet/IP standard's ForwardOpen Response. https://www.automation-pros.com/enip1/UserManual.pdf

Prepare to be disappointed.

Sounds like something you'll regret when the bandwidth bill comes in.  Point I/O is made for "class 1" connections with traffic all the time.  Presumably this is a private cell network space?  As long as your private network routes UDP packets, it should work.  Ping is not a sufficient test.

Normally, you would use a function parameter that the caller provides for any necessary context.

So, the manual for the levelmaster doesn't appear to be the correct one.  It shows Modbus output, not 4-20mA.   Assuming the 4-20mA version is similar, then it is a 4-wire transmitter, not a 2-wire.  You will need to supply power to the transmitter separately from the 4-20mA loop. Then, you will probably need to wire the display into the signal loop as shown in the Vegadis manual, figure 17 in §5.5.  However, that figure shows an isolated PLC input, and your module is not isolated.  You might want to contact Vega for assistance, as they don't show the non-isolated case.  (Their internal arrangement of sensor and power terminals is not clear.)

A "positioner" typically refers to an actuator that has its own internal position sensor, power, and feedback loop (possibly purely mechanical) such that the command signal can be low-power and is expected to be nearly linear with valve % open.  In my ancient (25 years ago), a positioner with 5% hysteresis error would be immediately replaced.  The paper mill I worked at back then expected positioner error to be <1%.  Considering the potentially dangerous conditions you are trying to control, you should consider have the valve/positioner manufacturer examine it. That said, there's no magic to a high-pressure control loop versus any other.  The performance of the components will dictate the overall performance of the system. If you cannot get the gross components to behave sufficiently well, consider adding a parallel, smaller pipe with a smaller control valve.  Configure the small valve as primary control, and program the large valve as a cascade loop with large deadband.  (That is, it would use the smaller valve's control % as its process value, with a permanent setpoint of 50%).

You definitely need to power your devices separately.  Per GE manual GFK-1504N, page 10-39: It also extremely unlike that the wiring for the display is correct, as what you show doesn't have the display and input module in series on the signal lines, as is typically required.  Do you have manuals for the display and the transmitter? (The input module is non-isolated, so it must be the last signal on the current loop.)

Are these devices loop-powered?  Are either non-isolated?  Show your circuit diagram.

That's the kind of fault information that would normally only be decipherable by someone with the source code.  So, contact whoever sells Proficy now-a-days.  Don't be surprised to be told that it is a bug fixed in a newer version, and you need to upgrade.  Or, perhaps, that it might be a bug, but you need to run the latest version to be sure.

Yes.  With a leading edge sensor wired to one of its Z inputs, where that input is configured to "latch and continue". Then, use a high-speed output on the encoder card to stop the analog drive at the target position, with an appropriate (speed-compensated) lead for deceleration.  If deceleration from normal speed is not sufficiently precise for your 3mm tolerance, use additional logic to slow down the drive early, then stop from the slower speed.

I'm not familiar with that particular drive, but the general requirements for the application described are: Capture an encoder count or position value, at the required level of precision, when the leading edge of the material enters the cut zone, and Command the drive to stop at the required ending position, again, to the required level of precision. Drives with positioning modes built in can generally do both of these operations, as long as some leading edge sensor is wired directly to the drive (for high speed capture). If your drive doesn't have any positioning functionality, or lacks the high-speed position capture feature, it all becomes much more complicated.  And possibly requires encoder signals to be brought to the PLC itself.

Your screenshots show a subnet mask for the PC, but empty in the PLC.  Both devices need a subnet mask.

You don't have the subnet mask configured in the PLC.

The connection manager application path specified in the EDS file is "20 04 2C 65 2C 64", which targets assemblies 101 and 100, not 150 and 100. It also completely omits any configuration assembly, which Rockwell's generic ethernet module cannot do.  But try using output assembly 101 instead of 150. { EDS file assembly numbering is not required to match actual assembly numbers.  Only the application path in the connection entry is definitive. } Meanwhile, the error code is troubling, because it reports an error in the route path, not the application path.  See §11.2 in my Ignition EtherNet/IP driver user manual for a public list of common connection errors. A wireshark capture for working and non-working connections would be helpful.

Most commonly, errors in buffer lengths. If you provide more details, I may be able offer more help. Aside from that, there are output buffer mode indicator options that aren't supported by the generic device.

I would read it as required to be zero.  (Now in §3-5.5.1.1, in my version of the spec.)

IT is usually your friend.  Until they move critical "IT" functions out of the production LAN.  Like a DHCP server that provides addresses in an OT LAN.  Or a database that machinery talks to on every cycle.  Such things need to physically reside on the OT LAN.  One of the criteria behind US-CERT's network partitioning and service placement guidance is that the OT world should keep running when a crisis requires it be isolated from the IT world (firewalls and DMZ shut down/cut off). (If your facility is considered critical infrastructure in the United States, and therefore subject to Department of Homeland Security regulators, your IT may find itself in legal trouble if they don't follow US-CERT guidance.  It is good guidance for everyone, though.) https://www.cisa.gov/

The AENT doesn't have inputs or outputs itself.  It is just the comms adapter.  You'll want to look at the installation instructions (from Rockwell's literature site) for each of the I/O modules you choose.  The installation instructions have sample wiring diagrams.

I avoid Set/Reset (Latch/Unlatch) coils where a simple seal-in branch meets application requirements.  Specifically to be as maintenance-friendly as possible. There are two places I regularly use them: In processors where Latch/Unlatch yields a persistent state (through program mode or power cycle) and a seal-in branch does not, and the application needs that bit state to survive an interruption.  Typical in Allen-Bradley processors. To set bits of registers that implement a "bar graph" style sequencer, where the sequence restarts by clearing the whole register. I avoid using stop bits or interlocks in the PLC where stop==true.  That implies that the wiring and/or remote rack communications are not fail-safe.  (Cut wire => stop.  Lost comms w/ zeroed comms buffer => stop.)

Your predefined function block probably has documentation that states whether you need to hold its input on until complete, or if it fires on a rising edge.  If the latter (fairly common), then you don't need to extend the single-scan pulse. (Not being able to see single scan pulses is also common.)

Just a timer. No loop. (Tasks run repeatedly, giving you the option to perform loop-like behaviors without an actual loop.) Have 3-second timer include its own output contact as NC in its enable, causing it to restart repeatedly.  Use that done bit (true one scan per 3 seconds) to fire your function block.

But you have to set the AT field instead.  And you are limited to the size of the FINS address spaces.  When using EtherNet/IP, the size of the data can be much, much larger.  There's a reason Omron adopted EtherNet/IP in their modern CPUs.

I have that version running on a 32-bit Windows7 VM.

The NJ and NX processors can certainly do cyclic EtherNet/IP comms, but they have no provision for slot addressing within a generic ethernet bridge. At least, not that I've figured out.  Can the PC Vision system emulate the Rockwell Generic Ethernet Module (single pair of I/O buffers) instead of the Generic Ethernet Bridge?