Jump to content

MarkCG

Members
  • Content Count

    138
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by MarkCG

  1. I remember reading somewhere that the idea behind LabVIEW was to make data acquisition as easy as creating a spreadsheet. That is anyone with some ability to use a computer and understand basic math could create something that worked for their purposes without being a programmer. Gradually more and more complexity and capability was needed and the professional LabVIEW programmer emerged, similar to how professional Excel/VBA programmers arose in the financial industry. But like everything the need for the professional LabVIEW programmer was a product of particular historical circumstances, and I think history has moved on. Since many big companies have invested a lot of money in NI hardware we will be some demand for LabVIEW programmers to maintain these system, but it will taper off over the decades. I think it will be like COBOL -- you'll have a few crusty old guys wading into ancient codebases to make fixes and smaller changes but no greenfield development. I may be wrong but I think NXG is NI's last gasp attempt to stay relevant and that it will fail. The attitude in most companies I have experience with is that "not owning your source code" is a major, major problem, and I don't see that changing. LabVIEW is seen as a sometimes necessary evil only. If NI wanted LabVIEW to stay relevant for years they would make it open-source, and keep selling hardware and software add-ons for it. But they know their business better than I do and what's good for me isn't necessarily good for them.
  2. Is there anything like Xcontrols in NXG? I didn't think there was
  3. 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.
  4. MarkCG

    Things I Hate

    at least it doesn't crash as much as it used to
  5. 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?
  6. 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?
  7. should we add Network Shared Variables to this list of left hand scissor features as well?
  8. I'm interested in learning more about it-- can we see the presentation? I have never installed NXG but this sort of thing is what would sell me on it. My superficial impression has been that it's, at this point, LabVIEW with vector graphics.
  9. Makes sense. To me it seems DCAF if very close is so close to doing everything I want it to, I'd hate to add yet another layer on top of it. Honestly my feeling is that all these frameworks are great but they are all using a lot of complexity to transform and stretch LabVIEW into something completely different from what it was meant to do originally. There has to be a better way, were Actors , state machines, tags vs command vs streaming data, and easily handling thousands of I/Os are fundamental concepts of the language.
  10. That's great, I had no idea! I'll take a look at it at least and see if I can maybe come up with something similar.
  11. I use DCAF for most of the things running on compactRIO. I like it, very easy to write static modules, much harder to write dynamic ones where it works correctly with the configuraton editor, though I have done it. Nice to be able to manage tags with CSV files. My biggest gripe about it is that there is no built in events / messages/ triggers. So if you have a module that needs to perform some sort of sequence that you want to initiate on user command, you have to do something hacky like increment an integer tag, or change a boolean tag's state. I guess you could also do that with RTFIFOs or queues, sending this kind of command data from outside or even inside the framework but I have not invested any time in that, and seems like it would be hard to debug.
  12. Daniel, thank you so much for sharing this and bringing it to my attention. So what someone would have to do is create a program that reads in a protobuf specification text file, and then uses VI scripting to create a VI that encodes a specific message, using the VIs in the library "protocol buffer encoder". Seems like the sort of problem that you can break down recursively-- once the protobuff specification is parsed into a tree. you start at the root and recurse down the tree till you get to a leaf node. Generate code for all the leaves, then as you recurse back up wire the leaf code together. Easier said than done though...
  13. how are protobuffs that different form flattening a LabVIEW cluster ? It seems like I may be implementing LabVIEW protobufs at my job. I keep checking this thread hoping someone will have done it already, because it really has very little appeal to me as a project, but I may have to.
  14. MarkCG

    LabVIEW Memes

    A LabVIEW programmable PLC for $99 + $59 per I/O module? This shouldn't be an April fool's joke
  15. All I/O goes through the FPGA, and you can program a cRIO with both a program running on cRIO real time processor and one on the FPGA (also called a "personality") . You do not however HAVE to explicitly program the FPGA. You can use the "scan engine" if all you want to do is read and write I/O at a rate up to 500 Hz or so. All your program logic can be done in a LabVIEW program running on the real time processor. Where the FPGA comes in is when you need to do things at high speed, or with very high timing precision . For example, you want multiple PID loop controllers that run at 10 kHz, reading an analog input as the process data and outputting the control signal on an analog output or as PWM signal. You can do this on the FPGA-- you wouldn't be that fast otherwise. That or doing things like responding to digital triggers to perform some action within microseconds, things that generally require you to access I/Os on the in microseconds. You can also use the FPGA built in digital signal processors to do things like fourier transforms of data coming in and a whole myriad of other signal processing things that's contained in the Xilinx IP that you can access on some cRIOs. You are more limited in the datatypes and functions you can use on the FPGA-- typically you do things in LabVIEW fpga code you would not do in normal LabVIEW. On the real-time side of the cRIO, you can do pretty much anything you do on a normal computer with far fewer limitations-- you have access to the internet, serial communication to instruments, all the various math and analysis VIs, pretty much anything except UI related things (unless you have cRIO with a display port) The host is generally just the thing you use as a user interface. PC, tablet, phone, what have you. Typically the cRIO has the machine's logic built into its real time program, and the "host" sends commands or makes requests of it to do something via TCP/IP, network streams, or even UDP. The cRIO handles those requests and then lets the host know whether it can do them and whether it did or not.
  16. update to this thread: we got it working on the cRIO 9068. See this thread https://sourceforge.net/p/labview-zmq/discussion/general/thread/87780372ed/ for details. Thanks to everyone here and Martijn Jasperse for all your help.
  17. thank you Rolf and SmithD, this helps. I think he is making some progress now by compiling on the cRIO although it's not working yet. I've informed him of this thread and will update if we can get it working!
  18. Turns out one of my coworkers is trying to compile zeromq for the cRIO-9068, but not having success. Anyone ideas or have the .so file available? We also have a cRIO-9038 which is a different processor architecture, maybe it will work there?
  19. MarkCG

    NI DAQ alternatives

    I was going to say beckhoff as well. I'm a big fan of the beckhoff "EtherCAT Box" series. https://www.beckhoff.com/english.asp?ethercat/ethercat_terminals_accessories_overview.htm . Very reasonably priced too and you can get rid of enclosures.
  20. What is the datatype you want to write? If the manual for the device say that a particular register is interpreted as a 16- bit signed integer (I16 ) you will need to use the type-cast function on the I16 data in your LabVIEW program and wire that that to the write single register VI. For single precision floating point values, which are 32 bits, the modbus device will typically have you write to two consecutive registers in memory, typically called the high word and low word. It's done this way because every modbus register is 16 bits. So what you do is this and wire the array of U16s to the "write multiple registers" VI. Usually if the high word precedes the low word in memory this will work. If not the you have shuffle the high and low word. Modbus is fairly old, dating back to the 70's and doesn't have built in support for flaoting point.
  21. Unfortunately you probably have to make a voltage divider but the Winford enginering terminal blocks are pretty useful for this because you can solder in your divider resistors and then connect the block to the module with a d-sub cable https://www.winford.com/products/brkdd37mf.php
  22. Fair enough. I will say that the old library did the job pretty well though, never had a problem with it, even running on something as old as a fieldpoint. I actually modified to make it faster on reads as well, and also to make communications library for a flowmeter that used a proprietary bastardized version of modbus. The core logic of it is pretty solid and worth looking at.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.