MarkCG Posted March 3, 2020 Report Share Posted March 3, 2020 Hi all, I was wondering if anyone here has had experience doing machine control with both LabVIEW and TwinCAT (not in the same project or machine) . I've been working with Beckhoff hardware and I'm impressed, and I'm curious about how the TwinCAT software compares to LabVIEW as far as ease of use, stability and bugginess, and the power and flexibility of the programming languages available, that is how versatile it is compared to a compactRIO, where it seems you can do pretty much anything. Also how does it compare to LabVIEW+ LabVIEW RT + LabVIEW FPGA software stack from a cost perspective? Quote Link to comment
Rolf Kalbermatter Posted March 4, 2020 Report Share Posted March 4, 2020 (edited) If your external hardware is EtherCAT based, then Beckhoff will be quite a bit easier to use. If it is heterogenous then IMHO LabVIEW tends to work better, but that is also probably my significantly greater experience with LabVIEW and all kind of weird external hardware in comparison with Beckhoff TwinCAT. Edited March 4, 2020 by Rolf Kalbermatter Quote Link to comment
MarkCG Posted March 4, 2020 Author Report Share Posted March 4, 2020 (edited) Thanks Rolf. The NI EtherCAT master leaves A LOT to be desired but I've successfully got it to work with Beckhoff EtherCAT terminals, even in star topologies. Fortunately I've gotten away from needing to deal with 5 different communication protocols to talk to random devices lately, as I've been able to control what hardware is used . Did you ever develop code in the TwinCAT/Visual studio environment and deploy it to a Beckhoff Industrial PC? How was that? Edited March 4, 2020 by MarkCG Quote Link to comment
Rolf Kalbermatter Posted March 4, 2020 Report Share Posted March 4, 2020 I have only done minimal coding in TwinCAT. Been involved on the side with such a project where we had to provide support to get a few NI EtherCAT chassis to work in a system with Beckhoff controllers, Bronkhorst Flow Controllers and several other devices. While the Bronkhorst, Festo and NI IO chassis were on EtherCAT there were other devices that were using Modbus and Ethernet communication and that turned out to be more complex than initially anticipated to get working in TwinCAT. I was happy to sit on the side and watch them trying to get things eventually solved rather than getting my own hands dirty with TwinCAT programming. 😀 1 Quote Link to comment
MarkCG Posted March 6, 2020 Author Report Share Posted March 6, 2020 Interesting, Beckhoff controller with NI hardware is the inverse of what I did. Going forward I can't see a situation where would use the NI EtherCAT chassis unless I needed to take advantage of the custom FPGA programming or maybe needed the special shock/vibe ratings. I really got shocked when I discovered how many more practically useful features the Beckhoff terminals and EtherCAT boxes have vs the NI C series modules and how cost effective they are. For example 50/60Hz bandstop filtering is selectable on all the analog inputs. This is something you have to implement in FPGA for C series or buy a specific module with filtering (9209?). Or short/open circuit detection on digital output modules. Using the "EtherCAT box" modules eliminated large amounts of control panel wiring and harnessing, and still cheaper on a by module basis. Quote Link to comment
Rolf Kalbermatter Posted March 8, 2020 Report Share Posted March 8, 2020 We did indeed have some FPGA operation in there including some quadrature encoding and debounce circuitry. The main reason it was done with the NI chassis was however that they were already there from an earlier setup and it was considered to be cheaper to use them rather than buy Beckhoff IO terminals. Quote Link to comment
Michael Aivaliotis Posted March 9, 2020 Report Share Posted March 9, 2020 Don't forget cRIO has RT so you can implement a lot of programming on the RT side for various scenarios. As a master of the LabVIEW language and NI hardware. I would prefer a platform that allows me to use the language I already know and love. I can provide a PC application that implements anything the customer desires. then I can configure a cRIO and implement ECAT, serial, Devicenet, DAQ, DIO or whatever they want using the same language and skills. If NI does not support the desired hardware i need to talk to, they have many other options like DLL calls and other ways of interfacing that I still have not found a specific limitation that I was not able to workaround to get the job done and still make the customer happy. Yes, there are other languages and opportunities. Anyone who has worked with ECAT has heard of Beckhoff. They pretty much came up with the standard and are pushing it across the industrial world. It's just another communications standard. NI and LabVIEW are at a whole other level above and beyond that. Can NI improve the tools they provide for ECAT, DeviceNET and others? Yes! There are some features of ECAT that the NI tools simply cannot access or configure. A lot of what NI implements is the basics of the industry standard. They rarely go above and beyond unless customers push for it. They have a checklist of industry compatibilities they try to maintain so the marketing looks good. So they still can do better. Recently they started adopting TSN which is very powerful and allows synchronized DAQ across cRIOs and cDAQ chassis. Technology is constantly evolving and I commend NI for always trying to keep LabVIEW on the forefront by providing hardware that keeps up with todays requirements. So as you can obviously tell from this post, I am not going to convert to TwinCat any time soon. However competition is always healthy and keeps companies like NI on their toes to make sure they are always providing value to their customers so they don't start wandering off to other solutions. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.