Jump to content

MarkCG

Members
  • Content Count

    145
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by MarkCG

  1. MarkCG

    Dear NI

    I agree with all your points. Definitely on making LabVIEW free for all purposes, if not even open source. NI may hang on to the mega-costumers for a while with its current business model. But eventually it'll get marked as a legacy software and slowly replaced by younger people with newer ideas and experience in different, more accessible languages. The idea that a company can sell a programming language these days is ridiculous when there are so many free alternatives. I am not counting the community edition. It needs to be free for any purpose.
  2. I would love to see NI do this. It would open up a huge new field of application for LabVIEW. I thought NI couldn't do this because of their agreement with Xilinx, to prevent NI from taking over Xilinx programming tools' share of the market. It would be a real chance for LabVIEW to survive and thrive.
  3. Hi Zofia we talked before but I'll all add my bit here to see if anyone else has comments. EtherCAT is very powerful but so many of those features are held back by the NI EtherCAT master. For example you can get diagnostics on each individual link slave to slave but NI doesn't show that. No official support for topologies other than line or ring. I have gotten it to work with an EtherCAT junction but nothing displays correctly in the project. No hot-connect groups like with TwinCAT. Configuring slaves with CoE is difficult. I use TwinCAT for that. Just the bare minimum is there in the master t
  4. I have seen this too -- looking for RT Get CPU loads.vi in the wrong place, breaking the VI. Not sure how LabVIEW gets into that state but it's been a bug for years. Deleting all RT utility VIs in your code, then adding them again seemed to fix it.
  5. Thank you Rolf and Tim. This crash has seemed to happen exactly one time but maybe with enough logging I'll figure it out. My other option is to just convince people get rid of ZMQ completely for this application and use UDP or TCP connection. The application is just sending data to one server anyways so ZMQ is not really adding much functionality anyways
  6. Hi all, I am running a real-time LabVIEW application that calls into compiled .so file. I am getting occasional crashes of the entire system, and the error log shows a segfault #Date: Mon, Jun 29, 2020 04:59:16 PM #Desc: LabVIEW caught fatal signal 18.0.1 - Received SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x0x4 #RCS: unspecified #OSName: Linux #OSVers: 4.9.47-rt37-ni-6.1.0f0 #OSBuild: 264495 #AppName: lvrt #Version: 18.0.1 #AppKind: AppLib #AppModDate: am I correct in blaming this on the code in the compiled .so f
  7. 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 circumstance
  8. Is there anything like Xcontrols in NXG? I didn't think there was
  9. 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
  10. MarkCG

    Things I Hate

    at least it doesn't crash as much as it used to
  11. 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?
  12. 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 perspecti
  13. should we add Network Shared Variables to this list of left hand scissor features as well?
  14. 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.
  15. 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.
  16. 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.
  17. 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
  18. 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 togeth
  19. 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.
  20. A LabVIEW programmable PLC for $99 + $59 per I/O module? This shouldn't be an April fool's joke
  21. 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
  22. 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.
×
×
  • Create New...

Important Information

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