pturmel

Not a bad idea.  I'd make it big enough for multiple control blocks--future use.

For anything that needs to be sent regularly, I agree with Joe that it should be reads initiated at the destination.  If the data transfer represents an unscheduled or semi-randomly occurring event on the source PLC, I would use a write from the source.

Sounds like a programming error.  For most such cases, the start command should be pulsed and only the not-stop command kept on. FWIW, wifi is extremely fickle if regular TCP/IP traffic is sharing the channel with UDP or bare Ethernet frame for I/O devices.  A brief surge in TCP traffic can drop a few UDP packets on the floor, and suddenly your drive is misbehaving.  UDP I/O on wifi when the channel is dedicated to the purpose is highly reliable.

I'm not a Mitsubishi guy, but this is what your three choices would look like in an Allen Bradley Logix processor.  Based on your description, you probably want "Output2".  

Ah, no.  Toddlers shouldn't be playing with electricity or machinery.

There are three possible patterns to a timed output pulse: Extend the input pulse to at least the configured time, Extend or chop the input pulse to exactly the configured time, or Chop the input pulse to no more than the configured time. It sounds like you want either #1 or #2.  Please clarify.

My condolences. { /snark. Ignition fan-boy here. }

The "configure" option could do that, if you played with it and saved a different static IP, and clicked to confirm on the popup that warns that communications will be broken.  Did you do all of that?  If so, do you remember what address you set? If you do remember, you can temporarily configure your PC to have a static address in the same subnet.  Then RSLinx will be able to see it and you can repeat the process to set the correct IP address.  (There's no "undo" option.) If, perhaps, you set the device to use DHCP or BOOTP, you can use Rockwell's tool for that to give the device a new address on power cycle.  After doing so, you normally would use the RSLinx "configure" option to change the mode to "static". If you cannot do either of the above, you may be able to get to the Panelview's maintenance page (varies by model, and might not be enabled). If you cannot do that, you may have to factory reset the PanelView.  Sorry.

Note:  I blocked Asad.  The website he (repeated) linked was redistributing Mitsubishi software via Google drive, possibly maliciously modified.

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.

Or just a bog-standard router between the two subnets.  The instance of Kepware will need to be configured to point at the MicroLogix.  There's no magic to make the connection happen without that part.

Those are supposed to be treated as equivalent, in both new and old versions.

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.

Pretty cool! I find such work really satisfying, too.

Did you enable any kind of routing on the remote end so packets from your machine know how to navigate to the PLC and back?  A VPN itself doesn't provide that.

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  

Share the EDS files, please.

!! Hmm.  Good word.  Old but experienced. (:

I have no idea what you are talking about.

It definitely cannot use RIO.  Nowhere in the docs does it show support for any PLC-5 devices.  Just SLC and MicroLogix.

You have to look at the specs for the product.  Other common chipset are from "Prolific" and have "PLxxxx" part numbers.  These do not behave like real COM ports as well as the FTDI-based devices.  I'm sure there are other chipsets.  YMMV.

If the USB->Serial converter doesn't have an FTDI chipset, expect problems.

Yeah, pretty sure you will need to specify your final two angles as 370 and 390 to get the behavior you are after.

When you cam an axis to a master axis, the cam function has to be applied for every point the master goes through from one position to another.  I don't see how what you describe could ever be possible in a cam function.

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