i like Mentat's idea for simplicity of interface.. though response time would be slower due 12ms interpolation time but... one is free to trade response time vs color resolution.
Sending RGB signals to LED source
-
mandem -
October 12, 2020 at 1:08 PM -
Thread is Unresolved
-
-
not bad... that would eliminate need for EtherCat shield but would still need interface from X12 to Arduino.
if isolation is needed, bunch of optocouplers would be needed (and resistors).
You mean considering only one LED is needed? Im happy to integrate the etherCAT shield if it simplifies things and allows use of more LEDs if need in the future
-
You could also trade off some time resolution for color resolution, some bonus fun time to figure out the protocol to use
I think response time will be more important. But would you mind explaining how this would work?
-
using three channels and "low speed" PWM for example:
Arduino could read the duty of each channel and use that value as preset for LED PWM
so
scale = 255/T
R=scale * t1
G=scale * t2
B=scale * t3
KRC interpolation time is 12ms. so if you want 256 increments per channel (T ranges 0-255), that would take 256*12ms = 3072ms or just over 3seconds.
it means from the moment KRC changes value, it could take three seconds before the LED color is actually changed.
but that is where tradeoff comes in. supposedly you are happy with 5-bit resolution and don't want to wait 3 seconds.
2^5 = 32 values per channel but there are three channels so this really gives you 15bit color pallet which is more than likely to be plenty.
if you don't believe me, pick same colorful photo at 24-bit, then compare that when image is resampled to 16-bit and then to 8-bit color space.
and what does that mean for time?
32*12ms = 384ms which is significantly shorter and you are only using 3 optocouplers, three I/Os and very simple code.
-
It all depends on what you're trying to optimize. For speed, then adding 15 or 16 optocouplers and doing everything "in parallel" would be the way to go, sacrificing some resolution.
If you want to reduce the number of optocouplers, then doing some time-domain multiplexing would be required, trading some speed. Just how many optocouplers you reduce to would depend on your minimum color resolution.
As Panic said, you could get full 8bit color resolution for all three channels using 10 optocouplers -- 8 for color data, 2 to encode which color. This would take 3 loops of the Arduino program to update all three color channels, instead of using the "full parallel" version.
Your program (probably in the SPS) would work thusly:
1. Set the "channel" bits to 0
2. Set Red data (0-255) onto the 8-bit cluster
3. Give the outputs 12ms to settle (if the Arduino can't keep up, this would need to be longer)
4. Set the "channel" bits to whatever value you've selected to mean "Red"
5. Allow 12ms for the outputs to settle
6. Set the "channel" bits to 0
7. Allow 12ms for the outputs to settle
8. Set your Green color data
9. Allow 12ms for the outputs to settle
10. Set the "channel" outputs to Green
And so on.
The reason for all the time delays is to prevent any "breat frequency" issues -- without allowing enough time for the outputs to settle every time they change, the Arduino might put the "green" intensity into the "red" channel, or vice-versa. If the Arduino loop is slow, you might need to increase the time delays on the robot side. 12ms is probably the minimum you can get away with on the robot, to guarantee separation between your color channel data. 24ms would be more robust. So with 24ms "Off" and "on" time for each color, a full color refresh would still only take 144ms.
Of course, there are multiple ways to go about this -- the above is just a brute force, off-the-cuff approach. If you wanted to get fancy, you could (with enough blood, sweat, and tears) build a slow-speed SPI interface in the robot SPS and bit-bang all of this out to the Arduino using just two optcouplers. But at some point, just buying a few more OCs is probably easier and cheaper.
Of course, this all assumes that you're driving all of the LEDs in the strip to the same color. If you want to start individually addressing LEDs, then we need a lot more bits, or a lot more multiplexing.
-
Thanks all very interesting. I gather we could work out the delay and have the robot start the outputs before the robot reaches the location at which the color needs to be active.
I've had a reply from Esmacat about setup. They recommend Ethercat -> 24 V PoE injector -> Esmacat(EASE) -> Arduino -> LED. It sounds to me like optocouplers and PoE have a similar function in the setup as the PoE injector, but they mention that the injector is because EASE is powered through 24 V Poe and Beckhoff devices may not be. I thought the reason for an optocoupler was to reduce the voltage from 24 V coming out of the KRC4 compact to 5 V for the Arduino.
QuoteThe hardware setup I recommend for now at least is to insert a 24 V PoE Injector after the Beckhoff devices by connecting an ethernet cable to the LAN port of the injector, connecting another ethernet cable from the PoE port of the injector to EASE’s IN port, and connecting the 24 V power adapter to the injector. The reason for this is because EASE is powered through 24 V PoE and I am currently unsure if the Beckhoff devices run on that as well.
-
If krc and arduino are talking via EtherCAT (or any other bus system) directly you do not need any optocouplers because all datatransfer is done within the bus system (there are no 24VDC or 5 VDC - only "true" or "false").
-
Im on the cusp of buying the hardware for this project.. Just wondering if I am right in thinking the easycat linked below will allow more outputs than the esmacat?
Are there any other differences, namely speed of signal?
-
what about searching for specs and comparing them yourselves?
-