BreakPoint
Rube Goldberg Code
LOL! @ Altenbach!!! ROFL!!! 
That's a very good example. Somewhat scary... but definitely funny!
You clearly don't understand how computers work. The global is a counter, which is incremented all the time, so if you want to get its current value, but you only need it a little later, you have to resort to some advanced tricks to delay getting the actual value. That sequence (including the coercions) delays the code by a constant amount of time.
altenbach wrote:
Just to keep the processor busy, we could subtract 1 then add it again a nanosecond later. 😄
tst wrote:
You clearly don't understand how computers work. The global is a counter, which is incremented all the time, so if you want to get its current value, but you only need it a little later, you have to resort to some advanced tricks to delay getting the actual value. That sequence (including the coercions) delays the code by a constant amount of time.
Yes, I changed the diagram constant to U16 and it started executing too fast because of lack of the "coercion delay". However, I got it "just right" by making the wire twice as long and adding three more wire bends. 😄 I will need to adjust it again next time I buy a faster computer. 😮
On a more serious note, this is a minimal illustration of what I might call "code buildup" caused by thoughtless debugging, tunnel vision, or multiple developers. Maybe initially the counter was connected directly to the node, but it was noticed that it's off by one so we add a +1, later we simplify the formula so the +1 is no longer needed and we need to subtract one to correct for it. Here it is more glaring and obvious, but once the code is unreadable due to poor layout and overlapping wires etc. and the diagram covers several screens, things like that will happen all the time: 20% of the code does real work while the last 40% undoes the garbage created by the first 40%. 😄
Christina wrote
On a more serious note, this is a minimal illustration of what I might call "code buildup" caused by thoughtless debugging, tunnel vision, or multiple developers. Maybe initially the counter was connected directly to the node, but it was noticed that it's off by one so we add a +1, later we simplify the formula so the +1 is no longer needed and we need to subtract one to correct for it. Here it is more glaring and obvious, but once the code is unreadable due to poor layout and overlapping wires etc. and the diagram covers several screens, things like that will happen all the time: 20% of the code does real work while the last 40% undoes the garbage created by the first 40%. 
You hit a nerve with those comments which prompts me ask for ideas.
Background:
I have often been asked to fix/enhance etc abomitable code. Being a "code by the hour" type, customers are justified in thinking "Is he just trying to shake me down for more money?" So I inevitably bite the bullet and just patch up what I absolutely have to patch and hope that all of those other problems don't show up before I get paid.
What would be very nice is to have a "Board of LabVIEW Standards" that we could use to get a third party opinion that we could site when advising our customers. To a limited extent, Darren's VI-Analyzer has been handy in these cases.
Just my thoughts,
Ben
Who even needs boolean diagram constants? They just clutter up the palettes with useless stuff.
To create a FALSE, All we need is the following:
(from http://forums.ni.com/ni/board/message?board.id=170&thread.id=307295&jump=true)
Message Edited by altenbach on 03-09-2008 05:22 PM
Ray wrote
"... where he claims that I should know this other person's code well enough to precisely estimate how long the work will take. My beef is that I found out the author of the original code took NI courses up to Advanced!!!!!!!!!! 
..."
..."I have spent days studying "houses of cards" developed by others and all I can be sure of after doing so is that "I don't want to touch a thing"! It was those houses of cards constructed of globals locals and SV's that motivated me to write a couple of my Nuggets. I had hoped that maybe one of those people developing the monstrosities I have to face tomorow will read them and take another approach.
We teach the NI LabVIEW courses and just taking the classes is no guarentee that they will "get it". In fact a good part of our buisness is with custmoers that have taken the full gambit of NI courses.
Fixed price projects involving third-party code is something I discourage at every turn.
In your case your reputation will be called into question if you fail to deliver! I think all I can do is pray for you!
May the "divine Wire-Worker" smile on your work and may all of your buffers be re-used.
Ben
Ben wrote:
Fixed price projects involving third-party code is something I discourage at every turn.
It's a 2-way street... 😉 Wait till they need help again! 😛
Here's something interesting to look at. Let's see if you can spot 8 errors. Remember that games? Where you had to find 8 changes in a drawing..
We're getting nasty, aren't we? 😉
http://forums.ni.com/ni/board/message?board.id=170&message.id=307494
Message Edited by JoeLabView on 03-10-2008 10:42 AM
Let's all hop on the merry go round...
In order to convert an array of U8 to an array of I16 we clearly need to convert it to a string and then use the Scan From String to parse out DBL, and then create an array of I16.
Clearly.
From :
http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=307785#M307785
Message Edited by smercurio_fc on 03-11-2008 09:16 AM
In order to convert an array of U8 to an array of I16 we clearly need to convert it to a string and then use the Scan From String to parse out DBL, and then create an array of I16.
Clearly.
From :
http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=307785#M307785
Message Edited by smercurio_fc on 03-11-2008 09:16 AM
