I have a real engineering question. In real life, is the redundant path actually used?
If I owned a system that had a redundant path, I would place an alarm on the backup path and treat its use as a system failure. Maybe we finish the current operation while in alarm state but this is not the normal case. But is this even needed? Do real system ever fail over to the redundant path? On Wed, Jun 10, 2020 at 12:04 PM Bas de Bruijn <[email protected]> wrote: > > > On 9 Jun 2020, at 23:51, Stephen Bell <[email protected]> wrote: > > > The BBB would be the master for my use case, with devices such as > servomotor drivers as slaves in a dual-redundant topology. I use the BBB > Wireless, and thus don't have the onboard RJ-45. > > > If you want the bus to be redundant, the master indeed needs 2 connectors. > In a normal non redundant setup all the wires make up a single ring. The > master receives back its original datagram plus what all the slaves added > to the ”train”. If there is a cable break, the master will never receive > back the updated datagram. > > I would love the BB to be enabled with the ti pru-icss ethercat stack so > it would act as a slave. Then maybe a HAL component similarly to the > Hal-pru-generic component could exchange HAL pins with the ethercat bus. > > I tried working on that a few years ago, bought an AM437xIDK > https://www.ti.com/tool/TMDSIDK437X <https://www.ti.com/tool/TMDSIDK437X> but > I didn’t get to the finish. I got stuck very quickly when trying to work > out how to get the ethercat slave stack working in a Debian image. > > Robert Nelson helped a lot to get me to build an image, and that worked > fine on that board/cpu. IIRC I got machinekit to work. > But the PRU icss and ethercat was a bridge too far for me. iirc the > ethercat slave stack code was made for an rtos so i had no clue where to > begin. My lack of (domain) knowledge. > > Bas > > The other industrial connections would also be necessary, particularly in > a push-connector form factor, rather than screw terminals (additional > points if they can be accessed when on a *DIN rail* > <https://www.amazon.com/gp/product/B07DS2G78J/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1> > ). > > Isn't the BBB a 'popular MCU'? The thread is intended to take suggestions > for a new machinekit cape design, not alternative MCUs. But if an EtherCAT > cape is as trivial as you describe, send me a production sample and I'll > pay a lot more than 2 cents. > > On Tuesday, June 9, 2020 at 4:25:43 PM UTC-4, Juha Heikkila wrote: >> >> Hmm out of curiosity why would you require 2 separate EtherCat ports or >> is it just for a ring topology? >> >> If you can settle for just one, you could run the igh EtherCat master >> stack on the BBB and use available LAN port. So if one is enough, no need >> to mixup the cape with the EtherCat stuff. >> >> ”Ideally” for an industrial approach you could do ”minimal” setup on the >> cape and then (I think someone suggested this in the past) make a bunch of >> EtherCat slaves. Using a microchip LAN9252 coupled with a microcontoller is >> relatively simple to make and somewhat cheap. From the top of my head ill >> say the 9252 requires some 50 components around it and most just resistors >> and capacitors. The EtherCat slave license ”comes with” the LAN9252 so no >> issues >> >> If you pair the slave controller with a popular mcu I think the community >> could do a lot in the EtherCat slave world. >> >> Just my 2 cents. >> >> tiistai 9. kesäkuuta 2020 Stephen Bell <[email protected]> kirjoitti: >> >>> Agreed on the massive requirements disparity. In my view, given how >>> saturated the market is for stepper-motor based control boards >>> (particularly the Duet 3, which can be controlled by a BBB/RPi) I'd prefer >>> a more Break-out-Board style cape to make industrial-level control more >>> accessible. >>> >>> My ideal cape would have dual etherCAT RJ45 ports, an RS422 or 485 >>> header with voltage selection for PLC/spindle vfd control, UART headers, >>> dual CAN headers and a small array of optoisloators for the other GPIO. >>> Biggest problem for this is the ethercat license, which is somewhat of a >>> pain... >>> >>> I also prefer the web-based GUIs locally hosted on the device, which can >>> be accessed across the network and use less resources than a driven display >>> and a native GUI, so I'd prefer a cape NOT be limited by a desire to have a >>> screen/monitor from the BBB. >>> >>> just my 2C >>> >>> On Sunday, June 7, 2020 at 12:46:01 AM UTC-4, Malte Schmidt wrote: >>>> >>>> I think the issue is always that the requirements with these machines >>>> are very different and that you never quite get what is needed. >>>> >>>> When I build the cape I use on my lathe I sort of used a modular >>>> design. I based this on a prototype cape and used those small optocoupler >>>> and level shift modules that you get from China for the maker scene. It >>>> looks quite like a hack but you might see the three opto modules in the >>>> back and the two level shifters here: >>>> https://forum.zerspanungsbude.net/download/file.php?id=188366&mode=view >>>> There is an external pwm-> 0-10V module as well (not shown) for spindle >>>> control >>>> >>>> I always thought about making this nicer. I would have done it this way: >>>> A cape that: >>>> - Make PRU and GPIO Pins available in sets of 4? pins on standardized >>>> PIN headers + power. >>>> - Makes the terminals for connecting the cables available >>>> >>>> PLUS >>>> >>>> Small modules for level shift, opto isolation , spindle control (as >>>> desired). These would use the standardized connectors on the cape. >>>> For this I would actually rely on stuff that is already available (if >>>> so). >>>> >>>> -- >>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>> github: https://github.com/machinekit >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Machinekit" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/machinekit/4e75a7ba-b13f-4579-a7f1-09211ff4cbd7o%40googlegroups.com >>> <https://groups.google.com/d/msgid/machinekit/4e75a7ba-b13f-4579-a7f1-09211ff4cbd7o%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/61c7c2b7-e1bb-4c2c-8556-355bf16645b2o%40googlegroups.com > <https://groups.google.com/d/msgid/machinekit/61c7c2b7-e1bb-4c2c-8556-355bf16645b2o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/E3597AE0-5791-438A-981D-D941017C7FB3%40basdebruijn.com > <https://groups.google.com/d/msgid/machinekit/E3597AE0-5791-438A-981D-D941017C7FB3%40basdebruijn.com?utm_medium=email&utm_source=footer> > . > -- Chris Albertson Redondo Beach, California -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/CABbxVHty0M01OoS-Vke91nF6L%2BEhd3zEvyiEVdQcd2s%2B3_e15g%40mail.gmail.com.
