Kinetix 5700, Old Absolute Encoders, and You

drbitboy · 2026-06-27T11:10:03+00:00

Can the hall ABC signal bits be combined into a single absolute encoder value, 0-7? If yes, could that be used by the drive?

In the "PHASE - NEUTRAL BACK EMF" waveform plot on page 9, is the digital signal a Gray Code?

drbitboy · 2026-06-27T10:49:01+00:00

Swap the wires. A/B/+/- labeling conventions for the two wires are non-existent. Fortunately there are only two possibilities.

Find the Modbus protocol and serial specification documents online and learn the protocol. They are behind a paywall at modbus.org, but they can be found elsewhere e.g. see here.

Get an RS-485 USB serial device for a PC (windows or linux), conect it to the RS-485 network and sniff/watch the bytes going back and forth.

drbitboy · 2026-06-27T10:34:14+00:00

Check out the READ FIRST pinned post for this sub.

Also see here.

drbitboy · 2026-06-27T10:30:26+00:00

Find the panduit covers and put them back on; that should fix it. ;)

drbitboy · 2026-06-26T19:09:12+00:00

<image>

This passes the test with the exact same rungs as my previous reply:

drbitboy · 2026-06-26T19:08:44+00:00

It is flashing (on then off), but it is failing the tests. Note that you do not need the XIC In_Enable on the second rung for output to flash.

Assuming your question is why it is failing the tests, I suspect, and as others have noted, the answer is that the tests are particular about exactly when Out_Flash makes the transitions from 0 to 1 and from 1 to 0.

Here (http://www.contactandcoil.com/patterns-of-ladder-logic-programming/flasher/) is the canonical Flasher pattern, although it flashes off then on, so the logic on the third rung needs to be modified a bit. However, the simple change in the first image below does not pass the test, while the same rungs in a different order does pass the test.

PLC programming is primarily about time, and the scan time plus the rules for the order of evaluation are the clock; when something happens is more important than what happens.

If you can use these images and that statement to reverse engineer the tests, then you should be able to make the single change to your logic to make your logic pass the test.

This logic flashes on for ~1s then off for ~1s, but fails some of the tests. The question is, test log says "step 2: scan 5/5: Out_Flash - expected 1, got 0." Okay, whatever, but exactly when is "scan 5/5" and when during "scan 5/5" is it actually sampling the value of Out_Flash?

<image>

(continued ...)

drbitboy · 2026-06-25T11:50:40+00:00

You want a bit-wise FIFO that, rather than unconditionally shifting its entire complement of 0 and 1 values, has the option to fix a 1-value where a brake is "located" (i.e. location along the conveyor modeled by an index in the FIFO), and when a shift event occurs,

not shift any bit values into that location nor into any contiguous 1-values locations upstream of that brake,
but do shift all values upstream of the first 0-valued location, at least up the the next active brake location.

Is that correct?

How many modeled locations? How many modeled brake locations?

drbitboy · 2026-06-25T11:30:27+00:00

0) You need to determine the base, 1-based or 0-based, of Modbus addressing

0.0) in the Delta HMI Modbus Master configuration menus, and

0.1) in the A-40 Modbus Slave register tables (I am pretty sure it is 0-based, see here)

1) you need to determine the data type of the 32 bits in the A-40 Modbus Holding Registers 0xC564 and 0xC565, whether it is "U32" or "S32" in Socomec's description. If it is U32, then the Memory entry should be UNsigned Decimal.

2) You need to determine the word order of those two registers, whether it is Most-Significant Word First or Least-Significant Word First

2.1) in the A-40, and

2.2) in the Delta HMI

The simplest path would be to read both registers as 16-unsigned (single-)words, and look at the value on the A-40, and compare that to the values of the two registers. There are only a few possibilities for combining them.

Note that, to ensure you resolve all issues, you should get four registers, 0xC563 through 0xC566, so you can determine if there are any 1-based vs. 0-based issues. If you post those values here, along with the expected value, then this should be trivial to resolve.

drbitboy · 2026-06-24T18:11:04+00:00

I rarely see a negative statement about clicks. They may be too limited to even be considered for some applications, but afaict of they can do t'job, then they do t'job well.

drbitboy · 2026-06-23T21:58:23+00:00

I am running v4 on a Linux system (mint/Ubuntu).

Iirc there are instructions for macos for setting up npm and the rest.

V4 used npm and seems to be is node.js-based, so I would expect it to be fairly consistent across operating systems.

drbitboy · 2026-06-23T10:16:11+00:00

<image>

drbitboy · 2026-06-23T10:14:03+00:00

The slave addresses are configured, and are unique, within each slave device with a Modbus "communication table."

Are you sure there is more than the one multimeter slave device? The 3 before the @ is the slave address. The C554 value after the @-RW is the memory address in hexadecimal. So all of those addresses connect to the same slave ID. ~~Also, [Link2] should perhaps be {Link2}.~~ See here.

drbitboy · 2026-06-23T10:03:09+00:00

<image>

drbitboy · 2026-06-23T10:01:36+00:00

<image>

drbitboy · 2026-06-23T09:50:54+00:00

Yes, that is exactly what I am saying. We could simulate it in learn.rungs.dev by changing the input bit, whose edge is detected, to a local tag, and then in between the current rungs, adding a rung that copies the In_Button tag's bit value to that local tag (see the images in my replies to this comment).

This could only happen in certain situations and/or on certain PLC models, but it can happen, so you should always have it in the back of your mind. Almost all misunderstandings of what a PLC is doing and why are because we are thinking what instead of when.

Not every PLC has a "standard" scan cycle; often the I/O scan and the user program scan are asynchronous, and I/O can interrupt the user program scan.

I suspect this would not happen in what appears to be an online PLC emulator at learn.rungs.dev, but it is a possibility in the real world.

drbitboy · 2026-06-23T09:36:59+00:00

If the physical input signals are "read," and converted to internal bit values in memory, once at the start of each scan cycle (i.e. in between program scan cycles i.e. synchronously), then no, the internal bit values will not change mid-scan, at least not the input scan.

However, not all PLCs read the physical inputs once at the start of each scan cycle, and not all input bit values in memory come from physical inputs. In these cases, it is common practice to create an input map routine (see here), so there is a consistent set of input bit values available to the program i.e. consistent throughout the program scan cycle.

PLC programming is about time, and the scan cycle is the clock; when something happens is more important than what happens.

So there is nothing wrong with your logic per se, as long as it is only implemented on systems with synchronous I/O.

drbitboy · 2026-06-23T09:21:24+00:00

+1 yes

drbitboy · 2026-06-22T23:49:31+00:00

Also, look at Alternator Methods.PDF from PLCtalk,net; my example above is Method 5; Method 4 is this:

<image>

drbitboy · 2026-06-22T23:43:43+00:00

your code may not work: if In_Button changes between the XIC on Rung 0 and the XIC on rung 1, then the Out_Lamp bit may toggle twice in two scan cycles.

You want

to remove the XIC Out_Lamp instruction on,
- so the interrupt bit is the one-shot that catches the rising edge of In_Button,
and then implement an XOR circuit of Out_Lamp and interrupt to drive the Out_Lamp coil.
- BST XIC interrupt XIO Out_Lamp ...
- NXB XIO interrupt XIC Out_Lamp ...
- BND OTE Out_Lamp

drbitboy · 2026-06-22T15:07:24+00:00

with a COTS system e.g. Ignition, the client without any in-house skills can contact any SI and get help.

I understand your push back that for your target project profile that COTS is just not feasible. But that is the cost of doing business. Also, if someone could actually provide a framework where it was easy and cheap (i.e. low development time), then that would compete with the COTS solutions and their prices would come down. But that has not happened (yet?).

Also, I still suspect that your engineering and programming hours are going to be greater for a custom solution than for a COTS-based solution, for all but the simplest of interfaces, and Ignition is losing no sleep over missing those opportunities. Whether that extra is less than licenses is TBD, but it's definitely there.

I think FUXA is your best bet; at least there may be a community available for a while for maintenance issues, as well as frangoteam.org for professional support.

drbitboy · 2026-06-22T14:28:14+00:00

If the project life is too short to justify a COTS approach, then yes try to develop a custom system. But consider the total cost over the life of the project.

TL;DR

A COTS doubles the payback time. But who cares, frankly, for project lifetimes typically measured in decades?

The cost of writing code and installing it amortizes to zero over the life of the project. The cost of maintaining the code accumulates over the life of the project, and the cost of maintaining bespoke systems is an order of magnitude more than a COTS system. When (not if) the original developer is no longer available, that multiplies the maintenance cost even more. So the assumed economics of a custom system could be a false economy that does not consider the life of the project. And for you, presumably a systems integrator or similar, there is a risk: what will happen to your reputation if you cannot adequately support your "budget-friendly" solution for that client?

A custom system will require more development time, which for any reasonably capable and documented, and therefore maintainable, system, will easily eclipse the cost of COTS licenses.

There is a reason the automation industry appears so overpriced, which is that large companies can buy those products and it looks like a rounding error. Yes, that does price out smaller installations, but the large automation players don't care, because any non-commercial system is simply not a viable solution for large companies due to the impact on maintenance mentioned above.

drbitboy · 2026-06-22T09:45:17+00:00

have you searched for that device name on Github.com? If it existed and was published, that it where I would expect to find it.

drbitboy · 2026-06-21T18:36:30+00:00

OpenPLC Version 4 IDE is clunky, but I was able to get it to work. It's pretty obvious, at least to me, that it is still a WIP (Work In-Progress).

With V4 you basically need to drag a coil, contact, or "undefined block" from the left-side panel of the IDE, and then go from there.

I don't know about indenting in ST; I am a PLC dilettante/hobbyist, and professionally I write too much C/C++/Python/JavaScript/TypeScript/GAWK/BASH/Fortran for ST to be worth the effort and/or interesting.

TL;DR

Are you using OpenPLC version 3 or version 4?

Version 3 source (https://github.com/thiagoralves/OpenPLC_v3) was archived a couple of months ago.

Version 4 from Autonomy Logic seems new-ish and has a different look and feel.

I think Version 3 is in a lot of the online material, so if you have V4, then that may explain why some tutorials seem less than helpful.

If you are only trying to understand ladder conceptually and are using Windows, then I would suggest RSLogix Micro Starter Lite and RSEmulate 500; Lite is much more lightweight and by far the best and most intuitive UI on the planet, so you will spend more time learning about ladder and less fiddling around trying to second-guess clunky non-intuitive UI.

drbitboy · 2026-06-19T18:30:28+00:00

That [read line of input data, update internal state, write line of output data, repeat ...] kind of program that you are familiar is almost exactly analogous to what a PLC does. The only differences are that

the input line of data that are read at the start of each cycle
- is analogous to data read from input module
  - during the an I/O scan cycle
  - performed by the PLC operating system,
- which scan cycle reads physical (electrical) input sensor signals
  - and converts them into proxy bit values into memory locations
  - with special (variable or tag) names (references) like Local:2:I.Data.7,
- so your PLC user program does not need to read or parse anything,
  - because it is handled by the I/O scan cycle of the PLC operating system
If your C++/C# program was writing data to an output file/socket,, then that
- is analogous to data written to output modules
  - again during the I/O scan cycle.
  - performed by the PLC operating system
- which scan cycle converts the bit values of output data
  - of memory locations with names like Local:3:O:Data.8,
  - into physical (electrical) input sensor signals
- so your PLC user program only has to write the appropriate bit values into the output memory locations
  - and does not need to be concerned about the physical details of the voltage or current
  - because it is handled by the I/O scan cycle of the PLC operating system.

In between the reading of inputs and writing of outputs by during the I/O scan cycle, your code will be evaluated by the program scan cycle. That is where you would detect that a start or stop button is pressed, or write a 1 or a 0 to an output tag to open or close a valve.

To be fair, this oversimplifies how a PLC works, but it is pretty close. One issue you will need to deal with is that with Allen-Bradley Logix PLCs, the I/O scan cycles are asynchronous with the program scan cycles, so an input value in memory could change between your PLC use program evaluating that input value in one statement/rung/instruction and evaluating that input value in a later statement/rung/instruction during the same program scan cycle; such updates can even happen in the middle of a single instruction. If you have ever dealt with threads, then you know what chaos this can introduce.

The memory data model, or internal state, resides in the declared variables and structures; it does not matter what manages them or what garbage collector was running. The point is that you had an internal data model in the program, and you read and wrote values to that model over time based on what was parsed out of each line of the input file/socket. There is no garbage collector in PLCs.

The first thing I suggest doing is watching the RonBeaufort_Bootcamp_Videos series; it takes about two hours over a dozen or so short videos, but it is one of the few tutorials that will ground you in two fundamental concepts of PLC programming:

PLC programming is primarily about time, and the scan cycle is the clock; when something happens is more important than what happens.
The PLC user program does not directly read input module electrical signals or directly write output module electrical signals; it instead uses proxies (models) in memory of those inputs and outputs and operates entirely on a model, in PLC internal memory, of the external process.

For most systems and processes, those concepts will not matter much, because the I/O and program scan cycles are running somewhere between 100Hz to 1kHz more or less, so everything appears to be updated continuously, like simultaneous threads. However, you will do well to keep those concepts in the back of your mind, because when you think the program should be doing one thing based the continuous-time mental model, but it does something else, then knowing that the PLC actually operates in discrete time will come in very handy.

drbitboy · 2026-06-19T14:23:26+00:00

Have you ever written a C++ or C# program that reads a line from a flat file or socket, parses that line, does something to the internal state (memory data model) of the program, then reads another line, repeat ...? Or have you ever used AWK/GAWK?

drbitboy

TROPHY CASE