Jump to content

codcoder

Members
  • Posts

    58
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by codcoder

  1. Yes, exactly those signals! PXI Triggers. :)

    I don't have specific experience of the PXIe-7975R but I use the PXIe-7820R quite a lot. And on that card you can simply access the trigger lines like any other digital I/O in LabVIEW FPGA. So it would be fairly simple to use Wait on Any Edge or something like that.

    https://www.ni.com/docs/en-US/bundle/understand-flexrio-modular-io-fpga/page/fpga-io-method-node.html

  2. Hi,

    (This is a repost from NI's community forum. No answers there so I'm trying my luck here 😀 )

    As many of you are likely aware, TestStand is a powerful tool with numerous features and incredible flexibility. While these aspects are undoubtedly valuable, they can sometimes result in the creation of test sequences that are challenging to read.

    In my workplace, particularly with many newcomers learning TestStand, there's a tendency to be awestruck by its programming language-like capabilities, leading to the use of excessive loops, parameters, and if-cases where a simpler, flat sequence would suffice.

    Recognizing the need for clarity in test sequences, I've taken on the task of creating a style guide. The aim is to keep sequences coherent without unnecessary complexity.

    My question for the community is whether anyone has already developed such a guide and is willing to share it?

    Thank you in advance!

  3. On 10/30/2023 at 5:08 PM, Thomas_VDB said:

    I am also worried about the furture of LabVIEW. What worries me the most, is the help that text-based languages are getting now from AI. Code reviewing and code generation are already at a significant level, and are getting better every single day.

    I've always thought LabVIEW's higher level of abstraction somewhat reduced the need for that. But I'm not proficient enough in any other language to make a fair comparision.

     

  4. 17 hours ago, crossrulz said:

    Sounds like an OOP solution is what you really want.

    Well yes from a data structure point of view it is.

    It would make sense to store the private cluster as the private data of the class and use a public cluster as an exposed API. But solving the same issue with a library isn't that different.

    It doesn't however solve the issue of connecting the public and private data in some smart way. But @LogMAN provided an interesting solutionf or that! I'll look into it!

  5. 14 hours ago, Stagg54 said:

    It feels like you are trying to be too clever. Brute force seems like the easier way. Yes it's less elegant. Unless your cluster is enormous, I would probably just brute force it.

    So yes I went for "brute force".

    But I managed to solve it using VI scripting, i.e. automatically creating undbundle-by-name from the public cluster to bundle-by-name to the private cluster. So even if the creation process is obscure the result is easy to read by someone who knows only little LabVIEW. Which was what I was aiming for.

  6. Hi, 

    So I have this situation where I want to flatten a cluster to a byte array for data transfer. But as things are there are empty spaces between some of the parameters, call it reserved according to the format specification the cluster mirrors.

    So to make the flatten process as simple as possible I want to be able to traverse the cluster in a loop so the cluster must self-contain all information.

    I am currently solving this by including dummy parameters between the real ones to reflect these reserved areas.

    But of course, as you all probably agree upon, I do not want to expose the dummy parameters to the user (the vi will be accessed by Teststand btw).

    Som my question is: can some controls in a cluster be private somehow? And if not is there any other smart way to solve it? 

    My current solution to this is to create a "public cluster" without these dummy controls and move data between. So a secondary question is there any smart way to do that? I want to keep my code as flat as possible so my idea is simply to use bundle/unbundle but create it using vi scripting.

  7. 11 hours ago, Mads said:

    Maybe that is partly because the alternatives are not as good/many anymore, but let me be optimistic for a while...

    I must add that "small" doesn't necessarily imply "bad." I have never experienced LabVIEW, or the LabVIEW-centric world of electronic testing, to be anything other than a niche. But yeah, that niche can be strong and thriving or weak and struggling.

    To be honest, I don't know why I'm speculating here. I've been working for over 10 years, exclusively for two companies. I know very little about the world around me. There might be strong pockets of hardware companies with R&D labs equipped with NI equipment everywhere. I just haven't heard of them because they get overshadowed by the noise surrounding software, AI, machine learning, and other "hyped" technologies :D

  8. 1 hour ago, ShaunR said:

    Are you? What has front end web development to do with Node.js?

    The point I'm trying to convey here is that people often become closely associated with their roles in their respective fields, not necessarily as a programmer in the language that dominates in that field.

    For instance, if I've been a front-end web developer my whole career, how does that experience help me when trying to land a job as a data scientist? Saying that both positions use text-based programming languages doesn't cut it.

    If you ask me, the biggest problem with LabVIEW isn't LabVIEW itself but rather the fact that the field it excels in, such as electronics testing and measurement, isn't as thriving as many other software-centric fields that exist today. Our company has real-time test systems built with NI/LabVIEW. And we still develop new ones! Such systems aren't very common around here, with or without LabVIEW, compared to the plethora of companies making apps and other software solutions. Which wasn't the case 10/20 years ago.

    I am more worried about our company scrapping electronics testing altogether than moving away from LabVIEW. 😅

    • Like 1
  9. 1 hour ago, ShaunR said:

    The point here is that it's not the language that makes transition difficult. It's the awareness of the limitations of the environment and how to access the hardware.

    Isn't that always the case? You're a front-end web developer first and a JavaScript coder second. Knowing the syntax of the preferred programming language is just the first step.

    I do know that Python is often depicted as the culprit in the downfall of LabVIEW, but I hold the opinion that the main reason behind the perceived decline of LabVIEW is that the field where NI is dominant simply isn't as big as it was 20 years ago. At least from my own horizon.

  10. 15 hours ago, Bryan said:

    When I said at least one, I meant whichever one that I feel would be more beneficial to my own career ambitions, be it Python, Rust, etc.  I didn't (mean to) infer that they were generic and interchangeable, (I know better than that).

     

    Yes, I agree with that. Just because you know JavaScript as a frontend web developer doesn't mean you can transition to C and become an embedded developer. There is a need for more domain expertise than simply knowing how to code. I am not sure how common it is for programmers to switch fields and programming languages altogether.

    On another note, for me being a LabVIEW developer is a very unique role. It revolves around seamless integration with hardware; one cannot exist without the other.

    Ironically, this cross-disciplinary approach poses another challenge in our corporate world: it doesn't align well with the predefined roles and resource categories. You're either considered a software engineer or an electronics engineer—rarely both.

  11. I firmly believe there is a future for LabVIEW.

    But I have met too many developers who fail to see that they are the odd ones in a world of text-based programming. They fail to integrate into this world, and in the process, they also fail to demonstrate to other people the value that LabVIEW can bring. This only accelerates the downfall, as they are inevitably seen as burdens.

    I understand that this is an international forum, and so on, but your first sentence struck a chord: 'These are being slowly replaced by ODMs developing their own test solutions.'

    My questions to you: Why are these being replaced? What advantages do ODMs see in developing their own test solutions? And why doesn't LabVIEW integrate with this?

  12. I've always found it contradictory that LabVIEW itself, which relies so heavily on GUI, has such a limited selection of provided icons and buttons.

    Especially those useful for electronic testing and similar purposes: remixicon.com contains over 2000 icons, but the word 'electronic' yields no results. Additionally, the word 'test' yields only one result, an icon for A/B testing primarily used in software testing.

    NI: why you do this?

  13. When I did my first big LabVIEW OOP project (from scratch) a few years back I went "all in" with creating accessor nodes.

    Maybe it works better in other programming languages but in LabVIEW all those read write vi's clutters up. There are a few cases where it could be useful, like if you have a underlying property of the class (like time) and you want to read it in different formats (timestamp, string, double) making an accessor vi with small modifing code can be quite neat.

    Also I work with a real time application and since each accessor is a vi I'm not sure of it affects preformance. Extra settings like reentrancy needs to be taken into account I guess. So now when I'm trying to identify preformance issues I replace any accessor node possible with bundle/unbundle just to be safe.

    Fully agrees with @Neil Pate. Nowadays I'm much more restrictive.

    • Thanks 1
  14. 1 hour ago, leod said:

    It's about the same state of complete perfection as you see in a graveyard...

    Oh turn that frown upside down! 🙃

    The bug tracker for Python isn't exactly short either. LabVIEW is what it is. It isn't mainstream, you can't git merge, and as a developer I will perhaps never be understood by the text programmers, but at least where I work we like it and find it useful. 😊

  15. 16 hours ago, X___ said:

    It speaks volume about the state of LabVIEW when this becomes a new feature worth discussion on LAVA...

    One could argue that LabVIEW has reached such a state of complete perfection that all is left to do is to sort out the kinks and that those minuscule fixes are what there is left to discuss! 😄

    • Haha 2
×
×
  • Create New...

Important Information

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