Jump to content

jgcode

LabVIEW Tools Network
  • Posts

    2,397
  • Joined

  • Last visited

  • Days Won

    66

Posts posted by jgcode

  1. QUOTE (neBulus @ Feb 21 2009, 12:47 AM)

    The Modbus libraries that NI had their web-site where OK if that was all you were doing so they make a nice demo. They did not play well with other process. I went through and refactored them adding "zero ms wiats' to loops and some other stuff.

    FWIW, I prefer to use the IO Server when communicating with Modbus on RT rather than those VIs.

  2. [cross posted to ni.com]

    Problem:

    LabVIEW seems to be overriding a value of 1 to a value of 2 for the Sample Quantity.Sample Per Channel DAQmx Property Node for a Continuous acquisition mode.

    Information:

    I have a task set up in MAX (version 4.4.0f1).

    When I set Samples To Read to 1 the task runs correctly in MAX.

    When I read the task in LabVIEW (8.5) the Sample Quantity.Sample Per Channel property node (which is the Samples to Read) is coerced to a value of 2.

    If the value is greater or equal to 2 in MAX then the Sample Quantity.Sample Per Channel property node in LabVIEW returns the correct value.

    I get the same problem with a real device or a simulated device.

    Question:

    Is this desired behavior?

    Side note:

    If N Samples (finite buffer acquisition) is selected Samples To Read cannot be 1 as it causes an error 200077 - it must greater or equal to 2.

    But no error occurs when the task is saved as Continuous (continuous buffer acquisition). I don't know if this is related. The error generated is:

    Error -200077 occurred at DAQ Assistant

    Possible Reason(s):

    Measurements: Requested value is not a supported value for this property.

    Property: SampQuant.SampPerChan

    You Have Requested: 1

    Valid Values Begin with: 2

    Valid Values End with: 8589934590

    Device: cDAQ3

    Not Expected

    post-10325-1235031615.png?width=400

    Expected

    post-10325-1235031508.png?width=400

  3. Congrats on passing the CLAD

    QUOTE (crelf @ Jan 17 2009, 05:43 AM)

    Intermediate 1 and 2 are the key - If you've done and understood those, then you will be fine.

    IMHO & from an 8.2 course perspective (in case it has changed), the exam structure is based solely around Intermediate 1.

    Intermediate 2 (Connectivity - now & Performance) - although a great course, was not needed when I sat CLD

    Unless it has changed you could save some cash by doing just Int 1?

    I agree with what has been said already here:

    If you are ready experience wise (logged wire time is at appropriate level) then the following will help for the exam:

    Do the Int course, understand the course materials

    Do the online prep course

    Do the exams online &

    1) Ensure you complete them with time to spare

    2) Make sure the app works - all features in the spec implemented

    3) Following a recommended NI layout/architect (coz they will be marking it)

    4) Document everything (FP objects, SubVIs, Modules, etc..)

    Goodluck

  4. Congrats on passing the CLAD

    QUOTE (crelf @ Jan 17 2009, 05:43 AM)

    Intermediate 1 and 2 are the key - If you've done and understood those, then you will be fine.

    IMHO & from an 8.2 course perspective (in case it has changed), the exam structure is based solely around Intermediate 1.

    Intermediate 2 (Connectivity - now & Performance) - although a great course, was not needed when I sat CLD

    Unless it has changed you could save some cash by doing just Int 1?

    I agree with what has been said already here:

    If you are ready experience wise (logged wire time is at appropriate level) then the following will help for the exam:

    Do the Int course, understand the course materials

    Do the online prep course

    Do the exams online &

    1) Ensure you complete them with time to spare

    2) Make sure the app works - all features in the spec implemented

    3) Following a recommended NI layout/architect (coz they will be marking it)

    4) Document everything (FP objects, SubVIs, Modules, etc..)

    Goodluck

  5. QUOTE (zmarcoz @ Jan 13 2009, 05:33 AM)

    I see an MCQ, there are two VIs

    one is add 2 number together

    one is DAQ vi inside a while loop

    which one is simple VI

    both of them are simple and general<-- that is what I think

    This is terminology on design patterns from NI:

    Simple VI - block diagram is usually a component/function - typically a subVI

    General VI - block diagram contains parts e.g. initialise routine >> main (loop) >> shutdown routine.

    Therefore use the above terminology IMHO:

    "add 2 numbers" = simple VI

    "DAQ vi inside a while loop" = general VI

  6. QUOTE (Jim Kring @ Jan 13 2009, 10:37 AM)

    Oh great. I haven't even started working with Vista seriously and now I need to start thinking about (and avoiding) Windows 7.

    I wonder if Vista will just be like Windows ME and we can all just agree to forget about it, eventually.

    I think that is the point - MS were suprised at XP's extended lifescycle/the fact that Vista was a dud.

    Therefore MS are planning to market Windows 7 at all the people still clinging onto XP and won't upgrade to VISTA.

    Essentially bypassing Vista completely.

    I think the Vista interface is great, but issues with UAC, driver support, overhead etc..

    XP still has its place, it is lightweight and a great candidate for EEE PC's and smaller devices.

    Windows 7 feels very much like Vista from the GUI perspective.

    Under the hood tho it is going to need to be good to swing a lot of unhappy people.

  7. QUOTE (hooovahh @ Jan 9 2009, 11:23 PM)

    I'm sure this is just for playing around but I must say you are very bold to try to develop LabVIEW code in a beta operating system.

    Of course it is just for sh :beer: ts and giggles, but it would have been cool if it worked!

  8. I have an application whereby I am able to crash the LabVIEW Run Time Engine (8.5).

    1. My application consists of a Template VI (which is always in memory) that dynamically loads VIs into a subpanel.

    2. These dynamically loaded VIs contain LVOOP classes.

    3. In my Build Script in LV AppBuild I rename my LVOOP class VIs with a prefix (I have no inheritance) in order to try and neaten the build.

    4. I build the application (success) and run the executable.

    Randomly the LV RTE will crash when switching between screens (i.e. unloading then loading a dynamic vi into the subpanel).

    Sometimes on the first switch, other times the 50th switch.

    Fixes I have found:

    1. In the template VI I host an object of each LVOOP Class as a constant of the block diagram. This must keep the class in memory the whole time? As switching between screens in the subpanel is way faster. Seems to be alot of overhead in loading the different classes.

    2. Do not rename the LVOOP Class VIs (resulting build structure is more complex) in the build script.

    Either solution seems (thus far) to make the Application way more robust.

    Of course with inheritance I would be forced to use Fix 2 as with Fix 1 I would have to use the same prefix (which would still cause a name collision etc..).

    Question: Is there a known issue with the LV RTE dynamically loading/unloading VIs containing classes that have a prefixed name?

    If so is this fixed in 8.6 (I dabble in 8.6 at home from time to time but 99.9% of work is 8.5 or 8.5.1 so) I haven't tried with this app.

    There are some great reads on LAVA about related topics here and here

    [Cross Post]

  9. QUOTE (zmarcoz @ Jan 3 2009, 10:51 PM)

    1. I am in a different country but at the time it was ~ US$200 (discount for NI Alliance member may have applied)

    2. No, your objective is constructing a working VI from a given spec [E.g. Traffic Light, Security System, Carwash] and being marked on Functionality, Documentation and Style. It is software development, not hardware so there is no NI-DAQ, Serial and there is no ActiveX.

    3. Contact NI Training

    4. The manuals are great. You really only need Intermediate I as Intermediate II is about connectivity (VI server, TCP/IP, ActiveX) and whilst great stuff is not critical IMHO. LabVIEW For Everyone is still a great resource for CLD IMHO

    5. No, I am under the impression that a certain group of people at NI mark the exams for consistency so there is a turn around cost associated with this (they said 2 weeks in my country, but it was more like 4-5 weeks - but it was around NI Week time so I cut them some slack)

    6. [E-Kit] Yes read the course manuals, do the examples, the prep course, read lots (LAVA is great) and practice as time is tight for some (if not all) of the specs

  10. QUOTE (sachsm @ Dec 20 2008, 07:47 AM)

    I was thinking of caching the references but this could be dangerous if the PC restarts in which case I suppose

    the original references would be invalid. Just wondering if anyone could think of a more clever way to do this to avoid the time penalty of opening the reference.

    Thanks

    Hi Sachsm

    Perhaps you could still cache the references as suggested above but run them through a proxy on each call.

    I.e. if the reference is good (no error) use cache (fast);

    In that case that the reference is bad (error) then [run state machine] to open a new reference (slow), update cache, then use cache.

    Therefore you avoid the time penalty associated with opening a reference each time, but you have the proxy ready to kick in when needed to avoid an error that can be handled from a dead reference e.g. when the PC restarts.

    And all this can be relatively transparent.

  11. QUOTE (LV_FPGA_SE @ Dec 9 2008, 03:50 AM)

    I wrote that example and application note and would love to hear any feedback.

    Well I have used it - and I say damn good job.

    I actually integrated it into a license manager (client specification) for a third party device and am looking forward to using the NI Hardware component in an upcoming project.

    The application note was really helpgul and easy to follow.

    :beer:

×
×
  • Create New...

Important Information

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