BrokenArrow

QUOTE (TobyD @ Nov 17 2008, 12:10 PM) Hence the traffic light icons on the Semaphores. If a semaphore is a traffic light in LA where if you run it you die, then the global variable implementation of a semaphore is a stop sign, partially obscured by weeds and limbs, on an abandoned contry road where race conditions exist freely.

Ben and raggle, Very good points. And I've had each issue, resolved one way or another, when if fact the Semaphore would have been ideal. I'm not trying to be anti-semaphoric, I just needed a nudge. Thanks! :worship: This is deja-vu all over again. Five+ years ago, I was having a similar battle overcomming a bias against Notifiers. Now, I can't live without them. OK, I have three globals on my recent project... "Inhibit Port Acess", "Don't Write Now", and "Let The Other Loop Catch Up Before Proceeding". Time to change these to Semaphores. Actually, that last one sounds more like a Rendezvous.

Minh, Yep, a LV2 global, like OpenG's "Data Changed" is a great tool to prevent train wrecks. I agree that the structure of the semaphore is strange. Why on earth should there be a "Not a Semaphore.vi" if the structure were not conducive to abuse and mixing with other things? Val, Good point! It looks like 8.6 has replaced the CIN's with Queues and other dodgy bits, and 8.5 uses CIN's. Even NI agrees that it was never necessary to begin with! (kidding).

QUOTE (Jim Kring @ Nov 16 2008, 02:27 PM) Thanks Jim, Understood, that's obviously why the few times I've used them "casually" I ended up replacing them with globals, likely because I was using them (the semaphores) where they were not required. However, one example of where I used a semaphore and eventually changed it to a global was in a program that did exactly what crelf described. I had a parallel loop where two VISA resources had a slim chance of causing a train wreck. I ended up just using a global boolean. For the sake of argument this boolean was called "Don't Run". The boolean, wired to a case statement, was simply lit up appropriately to avoid dual access to the resource. Now, granted, this is a typical use of a "variable" which doesn't follow the dataflow paradigm etc etc, but it worked like a champ and I didn't have VI's that use code interface nodes (semaphores) hanging all around. Jim, is that example available electronically when you buy the book? I can't learn anything from the shipped semaphore examples. In fact, those examples only cement my bias.

I really can't see what you can do with a Semaphore that you couldn't do with a local, global, or a Notifier. Does anyone here commonly use them?

QUOTE (jasonw @ Oct 29 2008, 03:27 PM) Good troubleshooting point, but I do report timeouts (10 seconds) and give an option to quit the program or close VISA + reinit the port. I found the main issue with this one program: A PWM output was being set with a prescaler that was causing the cycle to be on the order of a few hours! That gave it the illusion that it was locked up.

QUOTE (Justin Goeres @ Oct 28 2008, 05:26 PM) This last program does use hardware with a "virtual com port". It's giving me fits. I'd like to be able to have a "rescue" button to reset comm with it, but when it locks up, so does my program.

QUOTE (jdunham @ Oct 28 2008, 02:14 PM) Thanks jdunham. I think you are spot on. I don't have the code with me at the moment, but the state machine takes us back to Idle where there's a Bytes at Port that runs once every few seconds, maybe that's what's reopening the port. I bet that's it. I need to wrap that in a False statement if the user has tried to re-link to the port. Overzealous use of the Abort button is also to blame. I need to hide it. :ninja:

Hello all, Once LabVIEW takes control of the serial port (sets it up, starts reading and writing to it) it doesn't want to let go, even if you've closed VISA, etc. In my experience, when your hardware freezes up (lets say due to a bad command sent to a device), you have to quit LabVIEW and restart. No number of serial port stops, breaks, closes will make it re-open the port with success. You have to close LV. On a similar note, If you've started LabVIEW and had any kind of serial comm going on, you have to quit LabVIEW in order to use Hyperterminal (or anything else). These two scenarios are related in that I don't know why LabVIEW holds the port hostage. Is there a way, while LV is still up and running, to simulate whatever is happening when LV closes and opens? Thanks, Richard

QUOTE (Neville D @ Sep 19 2008, 12:10 PM) That's cool, I didn't mean to intermingle the two subjects when referencing why I was finally coerced into using a lvprj. I don't expect to use much RT now that I'm done with the deliverable I did for the last company I worked for. Sadly, my current assignment isn't LabVIEW-centric. but I've ordered up some hardware to start a side project on my own where I'll be vooping it up new school!

QUOTE (Neville D @ Sep 19 2008, 12:10 PM) That's cool, I didn't mean to intermingle the two subjects when referencing why I was finally coerced into using a lvprj. I don't expect to use much RT now that I'm done with the deliverable I did for the last company I worked for. Sadly, my current assignment isn't LabVIEW-centric. but I've ordered up some hardware to start a side project on my own where I'll be vooping it up new school!

Sounds simply brilliant. Seems to me, LVOOP would be advantageous for larger programs. I was reluctant to use a LVPRJ when 8.0 came out, but once I did (upon being forced to by RT) I thought it was sliced bread, especially with the 8.5 improvements. Sometime soon I may feel the same way aboot LVOOP. I don't want this bad experience to taint my opinion of it. Time to check out the OOP Code Repository. thanks again Ben.

QUOTE (jdunham @ Sep 18 2008, 04:32 PM) That's what I'm going with, else my seven years of LabVIEW programming has been a waste if I can't add a freakin' analog input to a system! Thanks jdunham. QUOTE (neB @ Sep 18 2008, 04:20 PM) ....think of LVOOP as a way of managing type-def'd clusters and a set of VI's that go with them all wrapped in a single llb. The "class" is the cluster. The member VIs are the VIs in the llb that are allowed to use Bundle by name and Unbundle by name on that cluster. Ben That sentence helps tremendously, thanks Ben. When I stepped up to the program, I assumed the cluster full of different data types was just being used to carry and drop off data to different states of the state machine, however, it had a funny color! Thanks Ben!

Hello all! One late afternoon, not long ago, I was given a very finite time (like two hours max) to help someone with a LabVIEW project left behind by someone else. The new developer was having problems shoe-horning a new piece of hardware into a system. Piece of cake I thought, as long as there were available channels, I'll be home in time for Family Guy. Funny 3-D vi's.... Objects! I've never used OOP in LV. I found it completely impossible (given the time constraints) to edit the code and add the device into the available DAQ channel. Mission failed. I threw my hands up and agreed with the other developer that you "can't edit it". Once I wiggled myself out of the fetal position and the uncontrollable crying subsided, I substantiated my indifference to the code with the fact that nothing was documented, Then I ran accords THIS in the help... Because a LabVIEW class user only has access to the information you provide when you document the LabVIEW class, be sure to document the class and member VIs as completely as possible. Can someone please explain what that means?

QUOTE (PaulG. @ Aug 11 2008, 04:47 PM) I wouldn't use it... haven't used it... I share the computer in question.

QUOTE (iowa @ Aug 7 2008, 11:41 PM) I've used the HTML reporting in Teststand and found it to be ideal. It flows seamlessly into Excel after-the-fact, where analysis is (of course) a snap, and the color-coding is nice (red for failures, green for pass, etc).

QUOTE (TobyD @ Aug 8 2008, 02:44 PM) OK, FYI, I've had much better performance since uninstalling Google Desktop.

QUOTE (Tim_S @ Aug 8 2008, 09:44 AM) Thanks Tim. Coincidentally, I did that last night, and I *may* have deduced the problem: Google Desktop. Not sure why, but I don't really care, Google Desktop is a hog. I'll post another response when/if I know for sure. Richard

I think I have an issue with VISTA and LabVIEW, where I start LabVIEW and the CPU jumps to 50 to 60%, and when I quit LV, the CPU stays high until I restart the puter. Any thoughts? Version 8.5.1 and Vista Homer Premium 32-bit.

QUOTE (Gabi1 @ Aug 7 2008, 03:12 PM) Anything for a Futurama Fan (I have no date, a two-liter bottle of Shasta and my all-Rush mix tape)....

QUOTE (Yair @ Aug 6 2008, 02:51 PM) <Homer Simpson> I ... don't ... know </Homer Simpson> QUOTE (Yair @ Aug 6 2008, 02:51 PM) P.S. Next time, you might wish to create a development distribution for VIs you post. Whach you talkin' 'bout Willis? __ __Do you mean a llb?

QUOTE (Yair @ Aug 6 2008, 01:56 PM) That's exceptional! Thanks for the ideas. However, I don't think there's an easy way to A) Make the VI smaller while B) Having the pictures as an inherent part of the code, other than C) Using a more lossy format or saving the jpgs as lower quality, which could shave 50% off the size. I don't want to distribute 24 jpgs with the code!

QUOTE (azoutkast @ Aug 5 2008, 05:01 PM) Thanks for looking into it! :thumbup: :thumbup: ... welcome to LAVA!

Attached is a "match game" I put together. The pictures are based on Yu-Gi-Oh cards. The Interesting Part: Because the pictures are reasonably complex, and most adults don't play Yu-Gi-Oh, it generally takes adults LONGER than Yu-Gh-Oh-exposed children 7..9 to finish the game, at least in my testing. You'll need... Match Game.vi ( it's big because of all the pictures... 1.5MB?) Bool Array Changed.vi Search Boolean Array Until Done.vi I'd appreciate it if anyone using XP can tell me if the arrays look ok, and if the button array lines up OK with the picture ring array underneath. This may be used in a psychology department, and I have no idea what they might have. Maybe even WIN2K. Richard ********** EDIT: Later in this post is a LLB (in 8.2) rather than the three separate VI's.***************

QUOTE (TobyD @ Aug 4 2008, 01:02 PM) Toby, what's the "updater" and where did you get it? QUOTE (TobyD @ Aug 4 2008, 01:02 PM) Side Note: Any thoughts on the "cleanup block diagram" button? ....... I'm just glad they started it. Like any new piece of code, it'll just get better as the new releases come out. PCB and Schematic capture programs have been doing this for decades, so it's about time for LabVIEW. A zoom-in would be nice too. Also.. how far back will 8.6 save? to 8.5? 8.2? 8.0?