pturmel

PLC's use two's complement arithmetic like all modern computers.  When viewed in hex, I find it best to think of an odometer that has hex digits instead of decimal, so rolling backward from zero yields FFFF (or 32-bit FFFFFFFF) and then continues counting down.  Most PLC editors will simply show such values as negative decimal integers so you don't have to worry about the rollover.

I don't know enough about the ViewMarq to advise further.

What are your serial parameters?  I ask because Modbus RTU defaults to E-8-1 but requires two stop bits when parity is turned off.  A device that strictly follows the Modbus spec will reject N-8-1 transmissions.

Correct.  In Rockwell's notation, the dollar sign is the escape character that says "take the following two hex digits and make the single character from that code".  A real carriage return doesn't usually show up in a terminal program, except that following traffic is on a new line.

$0D, if interpreted the way rockwell does (and apparently Automation Direct, too), is simply the carriage return character. "0D" hex is 13 decimal--the code point for a carriage return.

I see many "$0D" that I presume are supposed to be real carriage returns.  But if they were, you would see line breaks on the terminal.  That dollar-sign+hex escaping is what Rockwell PLCs use for special characters when editing strings within Studio 5000 and friends.  The ViewMarq probably gave its examples that way, but you will have to convert those to the source PLC's convention for control codes.

I'm not familiar with that card, but it sounds like reasonable pattern on the face.  I'd probably go straight to an oscilloscope to compare PC versus PLC waveforms.

Pretty sure that isn't going to work.  It is a funky RS-485 pinout.

Do you mean for free?  We don't allow such things here. Contact Mitsubishi or their distributor in your area and PAY them for a license.

Meh.  I help solve people's problems for free, in public, for two reasons: I like to. It is good for my professional reputation. Both reasons have constraints on the time I may put in.  Questioners who put it some effort to help me help them will get more attention.

No, you usually need the whole folder containing it.  One of the quirks of InstallShield is that the installer is also used as the uninstaller, and a whole bunch of necessary metadata is placed alongside setup.exe in that archive location.

One more thing:  Using the UCMM instructions limits your service + payload to 500 bytes in each direction, include route path info if not a single hop.  Omron doesn't support spanning large tags over a series of continuing requests the way Rockwell documents it for their products.  Use a large connection to mitigate this.

Part of the problem is that Rockwell and Omron don't agree on how to represent booleans in their products.  For single booleans as tags or accessed as named leaf items in structures, Rockwell follows the CIP spec and encodes in a byte.  Omron encodes in a 16-bit word, even though it identifies it with the CIP data type. For arrays of booleans, or booleans within structures, all hell breaks loose.  For a complete explanation, see §3.3.4 in my Ignition driver's user manual. The net result is that it is almost impossible to get the structure CRCs to match, even if you get the length right. Strings are also different between the two brands.  You can usually work around this with an SINT array on the Rockwell side.

Today I Learned that this is possible.(:

Uhm, SLC 5/03 is a DH485 processor, not DH+.  The SLC 5/04 is DH+. Aside from that, I don't recall ever going through a SLC's Channel0 to get to a device on the bus.  If you have access to the bus itself, and you have the right interface kit, and you know for sure all of the addresses on the wire, you should be able to do it that way.

Well, that is part of the weekend, so all bets are off.  But otherwise, seems right.  (I did not audit your math closely.)

Oooo! I never noticed that feature.  Looks like a good way to get yourself in trouble (of both moral and legal varieties).  Particularly if trying to use an area scanner to protect humans without using reliable methods.

Your "hint" wasn't obvious to me.  Maybe the tone of voice in your head as you typed it would have made it obvious, if I could have heard it. This is a technical site frequented by many people all over the world, most with a literal mindset.  Mark your humor or satire if you do not wish to be misunderstood.

You cannot.  The safety program can only use input that comes from safety-rated sources.  Such a scanner should support CIP Safety, in which case the data will be marked reliable for the safety program.

Insufficient.  What if the run is 72 hours starting on Friday?  That simplistic approach would fail. I would divide the runtime by 5 days, keeping quotient and remainder separate.  Advance the date by weeks with the quotient.  Then advance by hours with the remainder.  If the hour-of-week of the endpoint is less than the hour-of-week of the start point, add another 48 hours.  Where hour-of-week is the difference to that week's Monday 8am.

I would call that a design flaw.  You have no other contactor between the power source and the motor.

Look at contactor 5KM2.  Its coil should de-energize when power is cut.  Verify that it isn't powered by something else.  Also check if one or more of its contacts have fused (failed closed), preventing its mechanism from opening when power is cut.

Uhm, cut the power to the inverter, too? But seriously, it seems the remote control circuits were not designed in a fail-safe manner (wire or power cuts == stop). Show the schematic.

As far as I can tell from the documentation, Sysmac Studio simulation does not permit network connections or EtherCAT connections or EtherNet/IP connections in the simulation.  You can only perform integrated simulation with an NA HMI that is part of the same project, or an NS HMI in CX-Designer. I'm pretty sure you will need a real controller to test MQTT.

I have exactly the opposite experience.  I've been running everything in Rockwell's integrator toolkit exclusively in VMs for the past ten years.  I move the VMs from system to system as I upgrade.  The underlying OS is far more capable than Windows for all kinds of networking, so it is a huge win on top of not having to do reinstalls all the time. VMs are not the problem.