BreakPoint
Rube Goldberg Code
@bsvare wrote:
I've sadly also met my fair share of horrible drivers. A lot of what I encounter are DLL wrapped VIs. Lately, though, I'd be happy to see that vs some of what I have been seeing lately.
For example, the latest driver I got has this "Init" function:
It requires passing in references to controls I don't use, need to know internal of which port is RS232 vs RS485, and Comport and MacID per connection. (Among other Rubes).
In fact, the "driver" is just 4 VIs, Init, Status, State, and Main (Demo VI)
At least the error chain is unbroken! You should have seen what this looked like before.
And it used "VISA.User Data" That's a no-no (Waves finger /\/\//\/)
User Data clears before the vi calling it goes idle (Not saved by VISA as part of the session that you may not need to explicitly open)
@bsvare wrote:
I've sadly also met my fair share of horrible drivers. A lot of what I encounter are DLL wrapped VIs. Lately, though, I'd be happy to see that vs some of what I have been seeing lately.
For example, the latest driver I got has this "Init" function:
It requires passing in references to controls I don't use, need to know internal of which port is RS232 vs RS485, and Comport and MacID per connection. (Among other Rubes).
In fact, the "driver" is just 4 VIs, Init, Status, State, and Main (Demo VI)
Oh, that sad and lonely Wait function at the left bottom... 🙂
@crossrulz wrote:
But the ones that really irk me are the ones that have DLLs to do simple SCPI commands. Seriously? Couldn't just use the normal VISA functions? Those I am quick to completely throw away and write my own.
Absolutely! We use TESCOM Pressure Controllers here. TESCOM have a DLL. They paid someone to wrap the DLL in LabVIEW VIs and provide that as a LabVIEW driver. I got a hold of the comms protocol to the TESCOM device and wrote a native LabVIEW interface. Now that mine is written in pure LabVIEW, it's portable to cRIO (Linux) etc. Much better 
Let's really complicate the creation of an array with what is really a 1-D array at the end of the day.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
Hmmm... It's exemplary for the rest of the thread (and code):
1. Write LabVIEW Code
2. Find less than 0 devices
3. Get infinite devices!
4. Profit $$$
4. Profit $$$
The Ferengi Rules Of Acquisition # 9 "Opportunity plus instinct equals profit."
@Gregory wrote:
wiebe@CARYA wrote:
Hmmm... It's exemplary for the rest of the thread (and code):
1. Write LabVIEW Code
2. Find less than 0 devices
3. Get infinite devices!
4. Profit $$$
In his defense...
Only case 1 and 2 did something, 0 was default... (That extra info makes the code less wrong, but 100% redundant!)
Here's one way to determine if the current code is run as executable (seen here).
Also that uninitialized shift register would be problematic if run more than once during a session.
I am pretty sure there is a better way!
