pturmel

MrPLC Admin
  • Content count

    783
  • Joined

  • Last visited

Posts posted by pturmel


  1. Network Time Protocol has broadcast modes (send and receive) and peer synchronization modes, in addition to polling.  Simple Network Time Protocol is NTP abbreviated to just polling.  I'm not familiar with those specific processors, but it wouldn't surprise me if they implemented the broadcast modes of NTP.


  2. I so hate proprietary names for common functionality.  Depending on whether VLANs are involved, "NIC Teaming" would be either "bridging" and/or "trunking" and/or "bonding" in ordinary managed switch terms.

    FWIW, it is common for hypervisor hardware to have either a single trunk to an upstream switch, or redundant (like Rapid Spanning Tree Protocol) trunks, while all virtual NICs in the guest VMs are bridged in the hypervisor to the appropriate VLANs (if any, in the trunks).

    You aren't crazy at all, except for being stuck with "walled garden" hypervisor vendor.


  3. Sounds like you need "register extension" to make  a 64-bit register.  If you are doing the adding in code, you would use your PLC's arithmetic carry bit to indicate when to add one to the 2nd register.  But if the register is external, (like an external digital encoder), you will need to monitor changes in the top two bits of the register to decide when to overflow/underflow into the 2nd register.  The pythonish pseudocode would be like this, where E is the external encoder, and V0 and V1 are the two 32bit registers composing the 64-bit result:

    # Catch forward rollover
    if V0.30 and V0.31 and not E.30 and not E.31:
        V1 += 1
    # Catch reverse rollover
    if E.30 and E.31 and not V0.30 and not V0.31:
        V1 -= 1
    # Copy low 32 bits
    V0 = E

     


  4. Sounds like you need a fast heartbeat included in the traffic in each direction, with short preset timers resetting on every heartbeat change.  If the timer expires, stop.

    After you've fixed that basic oversight in the original design, you can pursue ways to make the signalling itself more robust.  (Though you probably just need new high-flex cables.  They tend to have short lifespans.)


  5. 1) Should have been fixable with full documentation.

    2) Concur.  And they are apparently switching to an subscription model, where your install stops working if you stop paying.

    3) Pretty wimpy OPC server, from what I've seen.

    4) What?  There are plenty of OPC products that will reliably obtain and report data changes down to the single-digit millisecond range.

    Aside from all that, the NJ/NX family supports EtherNet/IP for tag access, and is well documented.  (I recently included high-performance support in an Ignition driver, fwiw.)  There are open source libraries that will help you create the appropriate ethernet traffic, and not just on Windows.


  6. Are you using the proper GE cable?  The ports on these processors are not RS-232.  (I'm traveling and do not have that cable with me, but it has electronics in one end.)


  7. It allows you to re-interpret the bytes that hold integer or boolean data as another format because the variables' memory allocation overlaps.  Similar to what can be done with byte array copies.  I don't find the unions to be very helpful, mainly because you are limited which data types are allowed.

    2 people like this

  8. 19 hours ago, BE said:

    The down side is everyone invariably uses a different program for VPN access

    Not only do they use their own VPN software, but most high-end VPN solutions reroute all network traffic through that company's firewall (in many cases, even LAN traffic to your own file servers).  Unless you are diligent about not opening the files of other clients while a particular client's VPN is running, you are likely violating any non-disclosure agreements you've signed with those other clients, and exposing your own corporate secrets, too.  I am extremely picky about the client VPN technologies I allow in my infra, and never allow anything that impacts my own LAN traffic.  Most clients end up approving the the very locked-down VPN I run through my own cloud server.


  9. In general, the U.S. National Electric code requires conductors to be protected from overload at the power source (external to your panel).  UL cannot waive this requirement, but might add more requirements.

    More importantly, most codes require externally powered conductors to be yellow or have a yellow stripe, to signify that they are not cut by the panel's own disconnect.  And, above 60V, will need separate arc-flash treatment.