@MK42 Yup, should've mentioned replacing the Arduino.
They do have a program running on the PLC, but the first step in the research would be controlling it from a clean PLC.
Interrupts do give an opportunity.
With your point on SCL and LAD being handled in the same way (which is actually very cool). Do you also mean that the changing of the output will only be done after the SCL loop finished? Then only the fast(er) interrupts do give a chance, but will decrease reliability of possible other programs running in the background.
The part on RS-485 / Profibus is actually another option that I will be researching. Which looks like a more solid way.
It does involve the need of using a microcontroller, but building a custom PCB would allow something more smaller, efficiently and "professional".
I'll look into hardware or software "decoding" of the profibus for that, but it's a whole other case indeed.
The LED strips will be used to indicate specific "parts". Thus they should be able to light up partially. Which isn't a feature of analog strips. I'm going to add it to my research and recommendation though
I believe Profibus could be handled in software, but might not be all too reliable (and hard to get certified), but that isn't a concern for this research. The LED strips are not a safety risk in any way.
Profinet would be one hell of a job to implement in software. I will atleast need a hardware ethernet receiver or something like an
XPORT profinet receiver
I have (in a previous project) used an XPORT ethernet receiver with a microcontroller, so I should be able to handle that.
My current options are:
Hacky SPI software implementation in PLC using interrupts (maybe get a bigger/faster PLC)
(Software/hardware) Profibus + microcontroller
(hardware) Profibus + microcontroller
Check the internet for an existing device with this possibilities.
@KalleOlsen
It doens't matter when I start sending to the LED strip (100+ ms)
But the actual message will/might consist out of 10.000 bits, so I would need a rate higher as 1 bit / ms.
I would prefer the PLC to start sending within 100ms and sent 10.000bits in another 100ms.
But that's also the reason why I would need a microcontroller. I can send profinet/bus commands that will make the microcontroller (hardware) rapidly update the bit-array. By clocking out the bits.
My research was to exclude the Arduino, as it brings in additional "problems". The company does not want to use Arduino's since:
- They might stop working (and no on-site engineers now how to fix Arduino's).
- They want to exclude as much of external controllers, also because of the reasons above.
- It takes more time to set up the system, because you also have to set up the Arduino etc. (You also have to program the Arduino before installing)
- When building/expanding/renewing the system, they need C/C++ programmers to update/change the Arduino code.
So they want to make the PLC do Arduino stuff
or ultimately have done a very well research on why a PLC can't do it.
And then I can show them an option like a microcontroller receiving commands from an PLC (so the PLC is the controller) and the microcontroller is just a "slave device" which has little "knowledge".
@L D[AR2,P#0.0]
The 2PULSE is a PWM module, which does not have the possibility to send "data". It'll only send an 101010101 signal. Which is usefull for analog LED strips.