Jump to content

ShaunR

Members
  • Posts

    4,855
  • Joined

  • Days Won

    293

Posts posted by ShaunR

  1. Ok, (as I posted above) I assumed differently, a quick test confirms that I was wrong, so that is good.

    I can do as per your example but I would still like to see something (i.e. throbber, status bar etc...) moving on the panel though.

    As a test I loaded the entire C:\ directory into a Tree it was taking minutes.... (I didn't wait for it to finish)

    So in this case, I would really like my user to see something moving during this time.

    I would very much like to keep it simple, but I workarounds aren't i.e. sticking the Tree in a subpanel OR having a VI overlayed (what if the user wants to be move the screen? O will have to synch both VIs) are currenly my only options? Unless there is a method for defer Tree updates I haven't seen? If not this would make a good Idea on the Idea Exchange IMHO.

    Doesn't get much simpler than an animated gif that is visible or not :P

  2. Also saw a slick demo at the last NI week that had a VI grey out when it displayed a modal dialog box. Pretty sure it was done with a simple image overlay using the alpha channel. Not sure if it was as simple as toggling visibility, or if it involved moving the image from an off screen location, but it looked really slick.

    I quite like making the vi a little bit transparent (say 5-10%) it really brings the focus to the dialogue and is dead easy.

    But I'm +1 on disable and greying out controls.

  3. I've come across various variations of this over time

    How To Shoot Yourself In The Foot In Any Programming Language

    What about Labview?

    We need an entry in this prestigious list. Suggestions?

    This is my favourite biggrin.gif

    C++

    You accidentally create a dozen clones of yourself and shoot them all in the foot. Emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."

  4. Nope you are right (only 1/2 a rep point then wink.gif) When I launched your example (dbl clicked) it switched to 2010 instead of my usual 2009. Making sure 2009 was open when I dbl clicked made sure I was using 2009, and it worked ok without moding.

  5. Ok, so removing the include datatype fixes the issue. And adding back the strict typedef setting has no effect. So my bug is the 'include datatype' problem. FWIW, the original with all the data types included and the strict type defs still works in 2009SP1 (this has been in my code since 8.2 and always worked until upgrading to LV2010)

    Here is the LV2009SP1 version where the datatypes are included and the typedefs are strict and it generates no errors.

    Variant to Data bug 2009.zip

    But NI did find a bug with the strict type defs. Here is the example from NI support where they demonstrate the strict typedef bug using simple datatypes:

    7299252 Variant to Data bug.zip

    I might get two CARs out of this one. Nice... rolleyes.gif

    Your example of the 2009 also fails on my 2009 SP1 (error 91). But if I remove the strict type it works again. I can switch backwards and forwards between it working and not working, so I'm not sure what you mean by "adding back the strict typedef setting has no effect"

    Hmmm. 2 cars? I didn't even get a rep-point biggrin.gif

  6. If you uncheck "Include Data Type" on the VI server reference classes ( Run, abort. Text display tree etc). It works.

    And if you save it to 2009 and add the "include Data Type" it fails.

    A default setting has changed maybe?.

  7. Cross-post from here.

    Tangent from here.

    It seems I'm having more than my fair share of LV crashes. I'm running 2009 SP1 on a Windows XP Pro. Almost daily I experience a problem with LV crashing, either letting me know that the last time it shut down bla bla bla would you like to investigate bla bla bla. At least once a week I can't even get LV to startup and have to reboot my machine. Today the only way I could get it to start was to double-click my project shortcut on my desktop. That was dumb luck. Is there a super-secret setting I'm missing someplace in my .ini file or a super-duper-super-secret series of keystrokes I need to make LV a little more robust?

    Or is my intuition correct in telling me that LV 2009 is the buggiest and most unstable LV version I've ever used (and I've been at this since LV 5) and it's time to move my customer to 2010 because it just might be a little better?

    I absolutely hate and will resist at all cost changing sofware versions mid-project (actually, in this case, tail end of project) but 2009 makes me want to pull my hair out.

    :angry:

    I think its been slowly getting worse every iteration. There used to be a time when you might see "insane object at..." maybe 2 or 3 times a year, but you had to be abusing it. I often get 2009 disappearing when I delete something. blink.gif But its better than 8.x (IMHO) which was a complete crock...But I think NI realise this which is why they have said 2011 will be a "stability" release. My personal opinion that any software shouldn't be released UNTIL it is stable.

    Don't bet that 2010 will be better. See how many bugs are still existing from 8.x. (2010 Known Issues)

  8. Hello,

    I am struggling with the multi-loop architectures these days, can anybody share a multi-loop design pattern with the error handling loop included?

    Thx

    I think most people use some sort of Queue based error handling where each loop/subvi/process/task places a message on the queue which is handled by a dedicated error task.

  9. What should the config schema look like? How will I simplify setting up a test in the future? How do I stupid-proof the config file? What are the other signal parameters I haven't thought of?

    I thought a bit about this. Below is an example of a simple "possible" DAQ config file.

    One thing you can do to poke-yoke the file is have a "default" button which reloads (but does not save) the original config you decide on. That way they can always get back to a known "good" config and have "commit" and "Save" buttons, One which is temporary and will not be retained between launches of the software but allows them to "play", the other saves over the previous file. You can also do other stuff like having excel macros or create an interface for entry checking etc, but its not really necessary. Its really up to you. Its very flexible and scalable.

  10. In my project I have one task, 8 channels, and 8 scales. As near as I can tell users can't edit those in Max so this is effectively a default setup.

    I'm not sure about that. From the last time I used MAX. It was a case that in the project you create a MAX database file which is deployed with the installation (under the build specifications >>New installer>>Hardware Configuration). If that is the way you are thinking, then your "default" will only be applied every time you install as well as deleting any changes or additional tasks. Additionally. Once it is in MAX, I'm unaware of a method to "lock" a task so that it cannot be edited (jump in here JG) .

    However, if you create that task dynamically (delete if exists, then add it again) every time you run your software, you will have a task that can be reset to default just by re-running your program (or by pressing a button). And if you do that you have the major component of the file system/database implementation biggrin.gif

    I believe any custom setting will require a new task, channels, and scales to be set up in Max. New tasks are created only when significant parameters are changed, such as the number of signals being captured or changing the input terminals. Each Max scale will apply to a specific signal from a sensor, so there will be up to 24 of them. (On second thought... there'll be one scale for each setting on each signal, so there could be a lot of them.) I'll have a global virtual channel for each DAQ terminal giving me 8 of those. I think those scales and virtual channels will be sufficient to cover all combinations.

    This bit, I think, will cause them to moan quite a lot as well as being extremely error prone. If you had a way to "copy" the default then I don't think it would be so bad, but I'm unaware of a way to do that in MAX.

    When the test engineers are setting up a test they can go into Max and look at the Task details to see which terminals should be connected and change the sampling rate if they want. Then they go into the individual channels and modify the settings and scale to match the sensor signal they have connected to that terminal. There are a lot of scales to choose from but they are edited rarely, such as when I get an updated cal sheet for a sensor. If I'm thinking about this right, this should give the test engineers a lot of flexibility without completely overwhelming them. Are there any gaping holes I'm missing?

    Well. You could update the scales directly from the spec sheet (or an automated derivative) to make yours and their lives easier.

    Starting and stopping tasks during the test is out of scope right now. If they *do* come to me with that request, I'll roll my eyes, sigh loudly, and make them feel bad for even asking. ;)

    No abort button ? wink.gif What I meant was actually covered in your previous description, where they have to create a new task.

    That is a concern. The application doesn't actually use Max though. The app only cares about the Task. Max is just the interface for configuring the Task that will be run. I think I can design the app in a way that will make it easier to insert a new module that provides an alternate way to configure the Task for a given test.

    Indeed. Your application is relying on the most error prone part of the process (configuring MAX). This is what worries me. But I'm not sure what module you would want to write to configure DAQmx, since the whole purpose behind using MAX is so that you don't have to is it not?

×
×
  • Create New...

Important Information

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