Mike Ashe

Okay, problem solved, or I should say problem worked around. It turns out that you cannot wire VISA Resource Name controls of different classes together, but you can wire from the property:values from one to another. You can also coerce from a VISA Session to a string and then from that string to a VISA Session of another class. Go figure ... Anyway, attached is two VIs that take a VISA Instr class in and give a VISA GPIB Instr class out. But if you try to wire directly from Session to Session they break. Download File:post-45-1154550195.vi This uses property nodes Download File:post-45-1154550232.vi This uses string coercion This seems to work fine, so far, if anyone knows of a reason why not to do, this, ie, gotchas lurking, please enlighten us.

Hi All, I am working on porting a bunch of GPIB code from one project to a "sister" project. Unfortunately, the two projects somehow decided to use different VISA classes for the VISA Session name controls. Group A uses VISA class: GPIB-Instr Group B uses VISA class: Instr I am porting code from Group A's project to Group B. Naturally, you cannot wire VISA Sessions of different classes together. I tried to use the typecasts "To More Specific" "To More Generic" from the Application Control palette, but that did not work, you get broken wires. I also tried using the Type Cast from the Data Manipulation palette. That appears to work, in that you can run the VI, but when you get to the Type Cast node, more often than not I get "error: memory.cpp Line 352" followed by "you're toast!!" :laugh: and LabVIEW dies. :headbang: Well, it doesn't actually say "you're toast", but it might as well, cause LabVIEW really does die. At this point I'm mulling over a couple of options: 1. Humble Myself and ask for help here, to see if one of my fellow GWizards knows of a typecast method that I have missed, or has a VI that takes a GPIB-Instr in one end and through myriads of property nodes parses out the properties and stuffs them adequately into an output session of type Instr. 2. Manually change all the VISA Sessions in the ported code from one class to another (ugh, not very elegant, and very time-consuming, there's a fair amount of VI's & controls) 3. Try to whip up a VI Scripting gadget that will do the change automagically. I'd also be happy to use someone else's magic (and heap praise and thanks upon them) if they already have coded something like this. Well, thanks for listening, I'm off to the VI Scripting forums to check what's in goodie bag...

I would agree, as long as we change "you'll" to "they'll" since we are talking about someone else. I certainly am not going to try this, way way too much work. LabVIEW probably has several hundred person-years invested in it's development by now.

Ditto here, although I had a little more warning. I had really wanted to go this year, but the current client's projects were behind before I got here. Bummer. You know, we should start thinking about having a couple of mid-winter LAVA-OpenG mini conferences, say a long 3-4 day weekend, and have two of them, one on each coast, or East & West USA, then if there was good attendence and interest look at having one in Europe or Down Under.

NI has always made most of their revenue and profit on the hardware. They started out making GPIB cards and the hardware sales funded the development of LabVIEW. Actually, Jeff was not asking a question, he was answering the question, which was being debated rather vigorously prior to his article. I agree with his summation that LabVIEW is more than most GP languages, the marriage of the dataflow paradigm with a graphical syntax makes it inherently better than most other languages and makes it's potential way better. At the same time however, it has been kept below it's potential, with a consistency that cannot be an accident. I have asked various people at NI and several ex-NI people, "why?" over the years and have received a variety of answers, several of which were: - no answer, they just would not answer - lack of support resources, if they made it more GP they would have to support some database investment banker on Wall Street. They didn't know banking, but they did know DAQ. Stick to what you know. - limit LabVIEW to limit hardware competition's ability to quickly drive their HW - Staying under Microsoft's radar. If LabVIEW dropped in price, increased in GP ability and seriously started to crimp into Visual C<> sales it might attract unwelcome attention. NI has turned into the 800 lb gorilla in their field, but MS is Godzilla - Instead of trying to be all things to all people, great successes often find a niche where the state of the art is open in the field. They pour all their resources into being the best in their chosen field. NI did that, both technically and with their business model/methods. I have never heard any of them express any regrets on this aspect of NI & LabVIEW. It will be interesting to see if anyone steps up to the plate and tries to create a LabVIEW clone (open "G") (or closed for that matter) next year and after. It will also be interesting to see what NI's response would be.

To quote Dr. T and others, "The Software is the Sizzle, but the Hardware is the Steak". Can't say any more, but your estimate of 40% of revenue being from LabVIEW sales is high.

A Good Man, dressed in a rugby shirt, not a suit

Yep, Default case is a must, however... if you want/need real flexibility with your state machine you'll use the Default case to implement an interface to call plugin VIs using VI server. That way you can have your "factory-installed" functions/states and also run new "states" that you drop in a plugin directory, scan, list & load at startup time and search for a match in your Default CASE. If you match, run the extended function, if you don't, THEN go to a "syntax" error CASE. If you move your state decisions outside of the CASE frame(s) into a State Selector subVI that feeds your CASE selector, and then make that state decision a table based lookup (not necessarily even 2D, it can be 3D, xD or a decision-tree) and then make that table reloadable from file or modifiable at run time you can implement a "Psuedo-Infinite State Machine"* Cheers, :beer: *See NIWeek-96 "VISTE: Virtual Instrument Scripting Test Executive" presentation.

I can, since I was one of the technical reviewers for the 3rd Edition. It's a great book. They have just about doubled the amount of material, brought it up to date with LabVIEW 8. I won't bore you with more of my flowery praise, just go pre-order a copy, it's well worth it.

Take a look at ArgoUML at: http://argouml.tigris.org/ The host site, Tigris, has a lot of other great open source development tools as well. You also should look at Eclipse: http://www.eclipse.org/emf/ Which is Eclipse's "Eclipse Modeling Framework", lots of UML here. All free and tons of development person-years. Salud, :beer: PS: Chris, how can you not know what it costs? Quote from Endevo's purchase page: "In the US, Canada and Mexico our products are sold by VI Engineering. "

Second thoughts: A quick review of the other LabVIEW IMAQ book at Amazon shows that it did not fair much better in reviews. The lawyers thought it was great, but they were not buying it for the same reason as most of us. What both book's reviews shows is how hard it is to write a book that really meets all the needs of the different skill levels or readers in one volume and has enough original material and application examples to grab great reviews.

You should also post the bitmap file (zipped, if it is very large) "dibuix.bmp" that you have listed as your filepath constant. That way we can see, & play with the whole sizes of holes and offer more well rounded holistic advice. By the way, before crelf says it, yes we know, droll, very droll...

A couple of quick comments, maybe more later. 1. The list price is kind of high. I'm not saying that it is not worth it, but it is higher than the typical LabVIEW book and therefore sort of sets the buyer up to have very high expectations. If you don't shoot a hole in one, or at least an eagle, then they feel let down. A birdie only gets you a "so what" and hitting par is considered a failure. 2. I note that there are multiple used copies for sale, some for almost twice what the retail is. So obviously someone (actually multiple someones) thinks it's worth a lot more than list. 3. The young lady has only written one review, so I wouldn't give too much weight to her blast (ouch, would you like some ice for that burn...) 4. I do not have a copy but read several sections of a friend's copy and found it useful, even though I had experience with image processing and LabVIEW dating all the way back to ConceptVi days. 5. I said it elsewhere on the forums here, but I'll say it again, a new version is needed. NI has added A LOT to the IMAQ module and I think it might be worthwhile to mention other image processing optins, like Irene's image processing system, based on the open source Intel libraries.

Actually there are probably multiple better flavors, but which to use depends on what you are doing at the moment. Also be aware in accepting advice on state machine design that some people have preferences and beliefs about them that border on fanatical dogma, yours truely included sometimes. There have been a lot of articles and code examples posted on this subject over the years. have you tried a simple google on LabVIEW and state machine? Same thing on the info-labVIEW archives and here at LAVA? Same thing at NI? Did you look at the LabVIEW \examples? You might want to start looking at an NI article (with code) about LabVIEW Application Design Patterns Also: Application Design Patterns: State Machines And be sure to read this article: Design Patterns with Event Structure You could also download and install the OpenG Commander at SourceForge, then afterwards, open it up and study it. <Fanatical Dogma On> Both your example and some of the ones above use enums as the input to the CASE in the SM. I prefer text input to the CASE selector as it allows you to parse strings, scripts, etc and use some of that directly. I think it gives better flexibility. Others will argue that with an enum you will never get an unknown state command type of error. I agree with the sentiment, but I give more weight to the flexibility. Just personal preference. YMMV. The best bet is to learn two or three state-machine design methods, so you can decide which to apply based on your current project, rather than looking for the absolute "best" type of SM and then trying to fit everything into that. <Fanatical Dogma Off/>

Possibly, try the following: To register DLLs or OCXs: On the Taskbar, select Start > Run In the Open field, type regsvr32 "<path>\NameOfFile.extension", where <path> is the directory where the file is located on your computer and NameOfFile.extension is the name of the file. For example: regsvr32 "C:\Windows\System32\Mydll.dll" Press Enter. If the file registers successfully, you'll see a message telling you it succceeded: To register an executable, or .exe, file: On the Taskbar, select Start > Run In the Open field, type "<path>\NameOfFile.exe" /REGSERVER, where <path> is the directory where the file is located on your computer and NameOfFile.exe is the name of the file. For example: "C:\Program Files\MyAppLocation\MyApp.exe" /REGSERVER Press Enter. Most executables do not display any message boxes when registered. It depends on how the application is created. Some applications when registered may open on your computer. Hope this helps.

Another big CONGRATS !!! Didierj, from a Dad who also had a daughter first, then a son. I hope you have many blessed years of happiness with both.

If you just want to take general advantage of having more than one core then you use multiple loops and good coding style to prevent the loops from interferring with each other. Where it gets harder is if you have an app that is straining your available resources even with 2 CPUs and you have to try to balance between the two. Sounds like you don't have to get into that for your application though.

And I thought I was hard on HH's :laugh: Perhaps we should have a year end "best of poetic posts" topic for each year and include a subcategory of HH posts and pithy replies. If we were really kind we might even delete the names to protect the guilty...

And this hierarchy is one of the key claims in the original LabVIEW patents (over 10 years later...). So much for the "prior art" portion of patent office due diligence.

Hmmm, I wonder how old this parser was created? Was it published way back when? Might it predate NI's patents on the basic LabVIEW system? ...

and yes, it is rather pricey, not for casual playing around, although well worth the price if you have a serious project to work on. and *that* is really saying something in crelf's case: Image Aquisition with LabVIEW :worship: Speaking of that, and new features and API, etc, etc, ... any chance that there might be a new, updated version on the horizon? :thumbup:

You might als want to Google on LabVIEW Icon Editor, etc. There have been several free versions of icon banner replacement tools created by the community over the past few years that do exactly what you want.

The price point may be the real sticker here. NI has almost always been a "premium price or nothing" type of company. In addition, as Rolf points out, NI has the LabVIEW Embedded platform to build up and I wonder if Qubix was sidelined so as not to steal any of Embedded's sales. I can imagine some customers trying to make do with Cubix when the Embedded and maybe an Analog Devices Blackfin was the right way to go. Still, I hate to see it go, it was a neat gizmo.

Thanks everyone. Since I took a couple weeks off and sat on my 500th, I see that crelf has also hit the half millenium milestone and then passed me up. It has been fun being involved with LAVA, so an especially big thanks to "the other Michael" for starting LAVA forums and keeping it so independent of NI. This is a good place to be.

bsvingen, Thanks very much for posting both your final solution and the benchmarks. Very significant. Lastly, did you ever do any of your work in LV 7? Obviously the 8.0 Traverse tool/method will not work for 7 (then again, I didn't try to revert it to 7, but I suspect it won't.) There are still a very significant portion of the LabVIEW community that still use 7.x and I think they would benefit from your solution if it was finalized with the diagram coloring method. Again, thanks and good job! Scratch my paragraph above, I had not yet seen this post for your LV 7.1.1 version so please forgive the above. Thanks again & great job!