Rube Goldberg Code

[bsvare]

I love how we are having a conversation about who's producing a more efficient Rube. The irony.

[Hooovahh]

It's good to be self aware, and not take yourself too seriously.  Those are the people that are usually the ones most open to seeing things a different way, or changing for the better.  That being said if you post some of my code as a Rube my knee jerk reaction will be to defend it.

[Blokk]

Interesting implementation of a Producer/consumer. Lets use a string as a command, but transmit the data as a local variable! 😄

Seen here: https://www.laserquantum.com/download-ds.cfm?id=885

Well, you can even buy the software: https://www.laserquantum.com/products/detail.cfm?id=60

(well, I hope the driver was made by an intern, and the sold product got cleaned up...or not... 🙂 )

[Blokk]

Lots of fun to rewrite an old application. I find "interesting" code parts every day! 🙂

Interfacing a RS232 chiller. Error status response in 1 byte:

Implementation:

Ok, lets check for hexa values to capture error. The only problem, what if more than 1 error flag is present in the byte? Magic! No error! 😄

Fixed version:

Another interesting approach: the device expects the temperature setpoint to be sent as 2 bytes hexa string. Lets convert it this way: 😄

Would not be easier this way? :

[crossrulz]

---

@Blokk wrote:

---

Instead of the Type Cast and the Reverse String, use Flatten Into String.  It has an input for setting the endianness (set it to Little Endian).

[Blokk]

This is the classic case when posting a "fix" for a Rube-Goldberg construct is actually also a little Rube-Goldberg! 😄

Thanks crossrulz! 🙂

[crossrulz]

---

@Blokk wrote:

This is the classic case when posting a "fix" for a Rube-Goldberg construct is actually also a little Rube-Goldberg! 😄

Thanks crossrulz! 🙂

---

Well, here's another thing.  You can make that VI a little more efficient by not using the Case Structure around the code.  In the event of an error, none of the VISA functions will actually run.  But you are optimized for when an error occurs instead of when there is no error.  Which will happen A LOT more than the other?  I sure hope it is the no error case.  For more information see here: An End to Brainless LabVIEW Programming (there are some other really good things in that presentation).

[Blokk]

---

@crossrulz wrote:

---

@Blokk wrote:

This is the classic case when posting a "fix" for a Rube-Goldberg construct is actually also a little Rube-Goldberg! 😄

Thanks crossrulz! 🙂

---

Well, here's another thing.  You can make that VI a little more efficient by not using the Case Structure around the code.  In the event of an error, none of the VISA functions will actually run.  But you are optimized for when an error occurs instead of when there is no error.  Which will happen A LOT more than the other?  I sure hope it is the no error case.  For more information see here: An End to Brainless LabVIEW Programming (there are some other really good things in that presentation).

---

Yes. Starting a subVI always with an Error case around became kind of habit for me. But I guess the speed penalty doing this in usual codes are negligible (but of course I just do not need error cases for such VIs, that is for sure!)...

edit: and the presentation is very good!

[JÞB]

---

@Blokk wrote:

---

@crossrulz wrote:

---

@Blokk wrote:

This is the classic case when posting a "fix" for a Rube-Goldberg construct is actually also a little Rube-Goldberg! 😄

Thanks crossrulz! 🙂

---

Well, here's another thing.  You can make that VI a little more efficient by not using the Case Structure around the code.  In the event of an error, none of the VISA functions will actually run.  But you are optimized for when an error occurs instead of when there is no error.  Which will happen A LOT more than the other?  I sure hope it is the no error case.  For more information see here: An End to Brainless LabVIEW Programming (there are some other really good things in that presentation).

---

Yes. Starting a subVI always with an Error case around became kind of habit for me. But I guess the speed penalty doing this in usual codes are negligible (but of course I just do not need error cases for such VIs, that is for sure!)...

edit: and the presentation is very good!

---

If you go back through this thread.... You will find the penultimate case 

Spoiler

I went to his profile, peeked at his most recent post and.... posted it here.