-
Posts
3,448 -
Joined
-
Last visited
-
Days Won
293
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by hooovahh
-
are Boolean expression stopped like they would be in C ?
hooovahh replied to ArjanWiskerke's topic in LabVIEW General
Looks pretty good to me. The only improvements I could suggest (which I tried and have no real effect) is to disable debugging and automatic error handling, replace compound arithmetic with the native AND and OR. And I would assume LabVIEW could look up stream and find that the boolean array output isn't used and might optimize that away. But adding an indicator (outside the for loop with the other indicators) didn't change the result of the test. So in this situation LabVIEW does its job better than we can. Or rather the compiler can use things it knows and create code that performs better than we could create. And honestly this is one of the staples of LabVIEW programming. "Don't worry about it the compiler will take care of it." This statement is both something I've relied on, and something I've hated at times. The compiler isn't perfect, but I obviously trust it enough to rely on it daily. -
VISTA - Professional Software Engineering Tools for LabVIEW
hooovahh replied to crelf's topic in User Interface
Yeah some of us are dumb enough to actually host our first crapware. To be fair I think that is probably my second crapware attempt since my first attempt is gone forever. Once I discovered LAVA I realized that would be a better home for cleaned up code so I haven't put anything new on there other than the tray launcher which has EXEs and installers that I don't think LAVA would like. -
VISTA - Professional Software Engineering Tools for LabVIEW
hooovahh replied to crelf's topic in User Interface
Eh, it depends on how it is measured for sure. Back then there wasn't the code complexities that was added in 2012 or so, so coming with reuse metrics could be up for interpretation. I've used the code complexity for a reuse measurement metric in the past, and then broke it down into things like OpenG reuse, MGI reuse, vi.lib reuse (is that cheating?), and other reuse. Then there is reuse that can't really be measured like copying an existing library, or whole project from some old code (data mining), where here reuse is between 0% and 100% but code can't really detect the exact amount. Edit: I should probably force myself to get some free time and release my reuse metric, unless VISTA is going open source -
Yeah I made a thread, and then eventually a utility that attempts to make standard bookmarks easier to add. It can be invoked from the tools menu, or with a little work from a quick drop. It brings up a window that shows all the standard bookmarks, along with descriptions of each one. There is some that could ask for more information too, like a tag that is covering a requirement, which then asks what requirement to put in the comment. There is also a scan option for finding all tags already in a project. I honestly don't use this all that often, but I made it hoping it would encourage me to use the bookmark manager more.
-
What's your relationship with this customer? Will they beat you up on price and get you to agree to (X+Y*Z+W)*0.6? I don't have much experience with quoting freelance stuff. But in larger competitive bidding generally sales will tack on some percentage for overhead, then another percentage for a buffer expecting the price to be negotiated. Of course when you tell sales the bottom price will cost $100K, then they tell you the bid was won for $50K, engineers tend to get a little upset. (I'm not bitter, honestly)
-
are Boolean expression stopped like they would be in C ?
hooovahh replied to ArjanWiskerke's topic in LabVIEW General
LabVIEW can do some funny things, with constant folding, deleting dead code, and caching results from previous calculations. That coupled with the fact that UI elements are updated asynchronously, probes, automatic error handling, and debugging, can cause code that measure execution speed to be some thing that is trickier than initially thought. You may want to post the code you made which calculates this speed test so we can determine if it is calculating a speed properly. -
We've used a couple but the one I remember liking was by Supermicro, can't seem to find the model. A new standard 3U or 4U rack mount computer is probably going to be around $1K, but I think we budget for $2K. Something that looks like this one, but no with 8 ISA slots. http://www.superlogics.com/industrial-computers/rack-mount-pc-computer/SL-4U-SBC-H61-HA/269-5133.htm
-
Disclaimer that a lot of my knowledge on this subject is not from hands on, but research. I have lots of experience with cDAQ, and lots from FPGAs, but not so much when it comes to RT or embedded targets other than FPGA. When using a embedded target, you'll program on your normal host (usually Windows) machine and in the project you will add your target. Then you will write VIs for those targets and deploy from within your host. Then some level of debugging is done on that host machine, for the code that is running on the target, this always involves seeing front panels, but also some level of probing for some targets. (for example FPGAs don't allow probes breakpoints etc.) When using a cRIO almost all I/O go through the FPGA. There are exceptions for things like serial ports which I think just show up as a VISA resource. So full cRIO applications may have three targets, the FPGA, the RT, and Windows, all in the same project. But for debug you can temporarily ignore the Windows target, and for the FPGA you might be able to get away with the Scan Engine, which is a FPGA profile that just reads all data and sends it to the RT. So you might be able to get away with just needing to write one program, but then when you need more control you can write code for the FPGA, and then a custom UI might be needed on Windows. All three targets have the familiar LabVIEW IDE, just some have a subset of palette items. I have never used an embedded cDAQ chassis but I believe they are a target in the project and you write code and deploy it like before. But in this case I/O go through DAQmx and not through an FPGA. A lot easier, but less flexible.
-
I also think this is 2014, without any confirmation.
-
You know what I think is rube golberg-ish? Having cameras, vision, head tracking software, and lights to press a key. I think the foot pedal works, not that I don't think nodding for stuff doesn't sound fun.
-
Yes, a value change event does not necessarily mean a different value than the previous one. You can use the Value (Sig) property to set a control to the current value and the event is still triggered, same with this. The solution seems like an easy one. If the old value, is equal to the new value, do nothing. The old and new values are available in the event that is triggered.
-
Filthy Casual. But seriously yes I type with my hands on the home keys (stupid Mavis Beacon made sure of that). Swapping too many keys can be dangerous when I go to use literally any other keyboard in the world. The other issue is changing my brain to use keys differently. CTRL has always been that very lower left key, I can feel around to find the edge and know which it is. Changing CTRL and ALT sounds dangerous. As I mentioned I already replaced Caps Lock with CTRL because I just don't use that key.
-
Okay a quick update. I tried some behavior changes to make my life easier. I did get one of those Kinesis keyboards I linked to earlier (used cause who whats to pay that much), and I got the adapter that lifts the center of the keyboard and has the wrist guard. This is a bit difficult to get used to but I like it. I also bought an industrial foot pedal like this one, wired it to a Teensy LC (cause I had one already) and using the internal pull up I have it activate the CTRL key when pressed so I don't need to stretch my pinky finger. This change is harder to get used to because I need to have my foot in a resting position but ready to press, and then force myself to use that instead of my hand. It's possible and I use it for about 50% of my CTRL presses. I also went to the doctor and they said I have tendinitis which is a catch all term, and the specific injury might have a better classification. I'm now going to physical therapy for a month or so for some hand and wrist treatments. I'm also doing some hand stretches, and am doing better. As for the desk, I'm sorta in a lab environment without much extra space. The desk is a solid one that doesn't adjust, and probably a bit too high. I don't think changing it would be easy.
-
When are events queued/registered?
hooovahh replied to Scatterplot's topic in Certification and Training
Oh that reminds me, XControls have some kind of limitation when it comes to using user events, I believe you can't use user events at all, that are created from outside the XControl, and I wonder if when it executes and registers has something to do with this limitation. -
When are events queued/registered?
hooovahh replied to Scatterplot's topic in Certification and Training
Thank you very much for the correction, I've edited my previous post. For answering several questions in this thread I went and wrote code to confirm my assumptions. When it came to answering that question I just assumed I knew what it would do but as you mentioned gave the right answer to a different question. -
When are events queued/registered?
hooovahh replied to Scatterplot's topic in Certification and Training
I never really messed with this feature much, so I had to write some test code to see. It appears the locking of the FP occurs on static events when the event occurs, not when it is dequeued. Same goes for dynamic control references, if the register has the "Lock Panel Until Handler Completes" by right clicking the register for events. As for user events, it appears this isn't an option because user events don't involve UI controls. -
Yeah I opened these in LabVIEW 2015 32-bit and I don't even get prompted to save on close, no dirty dot, no recompile. I'm not convinced bitness is even saved in the VI. EDIT: Reading the block data the only thing that has changed between the two is the FPHb block, which I doubt has anything to do with bitness.
-
To me this seems like a matter of opinion, on how this tool should behave. If the purpose is to show the various versions of LabVIEW that are compatible with the VI, then I would think it should show both the 32 and 64 bit versions of LabVIEW. Because after all both are compatible with opening the VI. But I understand that showing the user the version it was last saved in might be helpful. Well to help out could you post a 32 bit and a 64 bit version of the same VI, and possibly two other versions that have separate compiled code or not. Looking at the private methods nothing jumps out to me as what you want, but there are some bit options that I can't predict what the values will be for other VIs. The other option is to look at the VI file structure on a binary level and find the differences. I suspect there might be something in there but again without any VIs to look at I can't say for sure. But there is the real possibility that this information just isn't in the VI. Source might not care what bitness it was saved in, so maybe NI doesn't save that information in the VI, only in the compiled code.
-
When are events queued/registered?
hooovahh replied to Scatterplot's topic in Certification and Training
Yeah I suspect new users think of an event structure as a type of interrupt, or goto function, and when dataflow is the name of the game, that just isn't the case. -
When are events queued/registered?
hooovahh replied to Scatterplot's topic in Certification and Training
When it comes to dynamically registered events, you are correct. If I generate a bunch of user events, then register for them, my event structure won't see the previously generated events, because it wasn't registered for them, when they were generated. Only events generated after registering will be seen and handled. It's like enqueueing elements, when the queue hasn't been initialized yet. But when it comes to static events, LabVIEW knows what it needs to register for. While I can't say for certain, I always assumed it registered for these static events, when the VI is started, before any code is executed. In actuality it might be registering for the events before the VI is even ran, but for this discussion it doesn't really matter. All that matters is static events are registered before code execution, presumably because LabVIEW can know what it needs to register for, and does it for you. When it comes to dynamic events you have more control over when to register and unregister so that isn't the case. As for your other question. Each event structure does get it's own queue to stack events onto. If you have two event structures, and they both register for the same user event (remember both register, not just register once and give that to each) then firing that one user event will be handled in both cases separately. This can be useful for a 1-N type of communication where one action is handled in N places, like a Quit event. When it comes to two event structures sharing the same static event, I think things are inconsistently handled. By that I mean if you have two event structures, handling the same boolean Value Change control, some times they both get the event, sometimes the first structure will get it and the other won't, or the sometimes the second structure gets it but not the first. Basically avoid this situation in all LabVIEW code. Because of this, and for code simplification, it is highly recommended that you only have one event structure for each VI, but that alone isn't bad for your code. EDIT: Still avoid the described situation, but as Jack said, I was confused about when this situation would happen. -
Not sure it is really an issue. I can't say for sure but I suspect the first time you try to do something like this, some DLL dependencies are loaded or opened the first time and cause some kind of delay where every subsequent write doesn't have that.
-
So a VI might not have the bitness in the VI, due to the fact that the bitness is in regards to the compiled code, which might not be int he VI file. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Property-to-get-LabView-Editor-bitness-32bit-64bit-and-patch/idi-p/2978707 That being said I'd suspect this information is available somewhere in the VI as a private function, or the VI file structure itself. But for this tool I don't think it matters, because VIs saved in 64 bit LabVIEW can be opened in 32 bit LabVIEW and vise versa. So for your tool you can show the compatible version as both the 32 bit and 64 versions installed. Of course I don't have a 64 bit version installed at the moment to test with.
-
How do these FPGA XNodes work without all the abilities?
hooovahh replied to Sparkette's topic in VI Scripting
Nope I'm not. I didn't make the connection that you were attempting to use scripting to change XNodes, sorry. -
How do these FPGA XNodes work without all the abilities?
hooovahh replied to Sparkette's topic in VI Scripting
Are you sure? Because nothing in your reply has anything to do with XNodes, Hybrid XNodes, abilities, or anything this thread is about. If you have a question not related to the topic, then please don't reply to that topic. Make your own thread on LAVA, or on the dark side (forums.ni.com) in the appropriate subforum. As for your specific question, I've never done that in scripting but I always assumed it was possible.
