Jump to content

jzoller

Members
  • Posts

    285
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by jzoller

  1. Jim, I couldn't agree more.

    From my experience, the internet toolkit XML vi's are hugely inconsistent in their interface and the native LV schema is brittle to the point of being useless.

    I ended up writing a private API based around the MSXML support for XPATH queries, but even it suffers from versioning problems on different machines. I will admit, I didn't investigate the LabXML interface too closely because of its dependency on yet another library (Gnome's libXML2).

    Joe Z.

  2. Be sure to match to your specs. If you're going to have 5 barcodes on the label, you will probably want to read them all and differentiate, rather than trying to line up the correct one.

    I've used Symbol wedge scanners as well. They work well for single code scan. In the past, I've looked at a low end machine vision system from Cognex (this one) that would allow me to scan anything sales manages to come up with... The system seemed solid, though it was more expensive and only ActiveX interface.

    Joe Z.

  3. QUOTE(Aristos Queue @ Oct 3 2007, 09:11 AM)

    Although LV R&D has been working very hard to invalidate the logic of the universe on several key points, at this time, we are unable to circumvent "A == A" and "1 != 0". :P

    Obviously, the universe needs operator overloading. :rolleyes:

    Jim, I'm sorry, on the line that says "You should organize your classes on disk", should it say, "You should not organize your classes on disk"?

    Thank you,

    Joe Z.

  4. Another simple method is to grab a timestamp whenever the value change event fires, and toss it into a shift register. The next time the event fires, if the new timestamp isn't greater than the old timestamp plus some delay (100ms, for instance), just route the event into an empty case statement and do nothing else. It will waste some cycles, but, for user interfaces, that is usually invisible.

    For reference, if you tinker with the slider event change, you can measure how fast LV grabs events. On my computer in a simple test VI, LV can grab a timestamp every 15-16ms, but it fires value change events about twice that fast.

    Joe Z.

  5. Something I haven't seen on this post: money. Depending on the organization, it may be the only language your boss' boss knows, speaks, or cares about.

    Your NI sales rep should be able to quantify benefits for you there as well.

    Joe Z.

    P.S. Orko, that was magnificent :rolleyes:

  6. Hi Deirdre,

    Played a bit with the Generic Container Maps. Interesting stuff (and I'll ask some questions when the NI board comes back for me), but...

    Big icons. Really, really big icons. Huge. Ginormous.

    ...You're getting paid off by Viewsonic to sell 36" LCD's, aren't you? :ninja:

    Joe Z.

    QUOTE(deirdre @ Aug 15 2007, 03:23 PM)

  7. Nice find, and a very good demonstration. I can confirm this bug for 6.0.2, 7.0, 7.1, 8.0 and 8.2.1,

    Some observations:

    -Replacing the sub-vi graph with a simple data indicator: still bugged.

    -Replacing the sequence loop with a case statement: still bugged.

    -Replacing the clusters/arrays with dbls: still bugged.

    -Replacing the top level sequence loop with other error primitives (flatten/unflatten) and wiring the errors: still bugged.

    -Replacing the sub-vi value property node with a local: bug goes away.

    -Routing the error wire in the top level vi around the sequence: bug goes away.

    -The bug doesn't appear on the first run, but does appear on subsequent runs. Ouch...

    Looks like a ref to the sub-vi data is being incorrectly retained where the data enters the top level sequence loop.

    Very nice find!

    Joe Z.

    QUOTE(Wolfram @ Aug 6 2007, 09:00 AM)

    I've encountered the following bug: See attachment

    It is one of the bad and strange ones.

    Wolfram

    Edit:

    I've replaced the attachment. There was a race condition in the

    previous demonstration VIs.

    Wolfram

  8. QUOTE(sm07 @ Jul 26 2007, 02:50 PM)

    All of my data are either individual 'double's or booleans...and there are only about 10 of them in total

    If the global is written only in one place, and only read elsewhere, it might be acceptable. The problem with this implementation is that it limits future flexibility in the program, and programs *always* seem to grow.

    Bite the bullet and use a better structure. You'll learn the pattern for the structure (worthwhile in and of itself!), and never have to worry about what you (or someone else) will do in the code in the future.

    Joe Z.

  9. Hi Eugen,

    I think you are correct, the Read From Text File appears to open files directly in a Read-Only mode. As you said, you can correct this by explicitly opening the file using Open/Create/Replace File with the Read/Write option enabled, then feeding the resulting refnum into the Read From Text File.

    Not giving the read/write mode option on the Read From Text File primitive seems kinda silly, since the function spits out a refnum.

    Of course, having hard-to-spot right click options on the primitive seems like a step backwards as well :wacko: I guess it depends who's using the primitive.

    Joe Z.

  10. QUOTE(Thang Nguyen @ Jul 19 2007, 04:30 PM)

    Hi,

    Could anyone tell me which VI I should use as a control for a supVI, so by which I can pass different typoe of control reference? For example this can be different cluster.

    I want to make a general VI which can do samething on different kinds of clusters.

    Thank you,

    Thang Nguyen

    Hi Thang,

    You should be able to use an untyped cluster refnum to access generic cluster properties. On the front panel palette (8.2.1), drop a control refnum from the Modern, Refnum menu. Then right click on the refnum and Select VI Server Class..., Generic, GObject, Control, Cluster, Cluster.

    That should at least get you access to the Controls[] list of refnums in any cluster via reference.

    Something I don't know: is there a way to programmatically determine the original strict type on the refnum once it's been passed to the subvi?

    Joe Z.

  11. Just for Friday fun...

    As Stephen pointed out via Darren here, an XControl embedded in a custom probe is always "running", and allows exploration of the data probed after execution finishes.

    If the probe is for a refnum, the XControl will keep the refnum alive even after execution finishes (as long as the probe is open). This allows modification of the data and properties in anything with a reference from within a relatively simple probe.

    I could see this being useful for unit or off the cuff testing, given some development. You could even build your own custom editing menus. Does anyone else have a good use for it?

    Of course, in combination with some rusty nails, some very strange results might be accomplished.

    Have a good weekend all,

    Joe Z.

×
×
  • Create New...

Important Information

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