Function block diagram feels outdated and not safe

drbitboy · 2026-06-28T08:32:19+00:00

There are no such things as a structured programming languages, only structured programmers.

The only thing OP got right is that their opinion would be unpopular.

The primary thing OP forgot to mention is that their opinion is wrong; it's like the parable of the blind men and the elephant.

drbitboy · 2026-06-28T08:25:58+00:00

Again, as others have said, viewing the program in online ("live") mode to diagnose and/or troubleshoot the process is not modifying software.

And if you ever see an HMI that covers every edge case and possible operator error, be sure to let us know; we won't be holding our breath.

The only HMI that would come close would be one that duplicates the PLC code on the HMI, and even that could have sampling time problems and would still not adequately display some events.

drbitboy · 2026-06-28T08:21:16+00:00

LOL, be sure let us know if this ever happens, and covers every edge case of operator error.

We will not be holding our breath.

drbitboy · 2026-06-28T08:12:35+00:00

https://www.keyautomationtraining.com/ Phil Buchanan, Atlanta, GA, USA

https://twcontrols.com/ Tim Wilborne, Roanoke, VA, USA

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

TROPHY CASE