Leaderboard

I'm reminded of the saying... Software is like a fart. Yours is OK. But everyone else's stinks. Charge more because it stinks so badly I can taste it? That's a contractor question but my view would be the same. I wouldn't charge more. If I think software is too bad, I would decline the contract because you can't sit there and whine after you've taken responsibility for it. You've been contracted to do software! If I really must work with it. then I'll re-code it. I'd just escalate the time-scale to account for the "learning curve" and "recoding". Then they can either accept or decline.

That sounds like you would charge more. Not as a penalty for foul-smelling code, but because you're being realistic in that you'd have to include the learning curve or the time to rewrite it. My take on the question was that Ben was asking was whether it would be ethical to charge above your standard rate to extend a particularly odoriferous project (after accounting for the things you mentioned) simply because the work involved is so distasteful?

This is regex we're talking about

Yes, unless it's your [company's] code! I don't think the reason for charging a premium, or even that a premium is involved, is important. It might, however, come up in the discussion after the customer receives your quote.

If it is false only the reference you wire to it will be closed. If it is the last reference, the queue is also destroyed regardless if you set it to true or false.What can happen is that you get "intermittent" failures if you don't get the close exactly right. Since one part of your code may close the last ref just before another part tries to dequeue/enqueue etc.. Then a loop that obtains a reference comes around again an re-creates it but you cannot track down where the error is coming from.

WOW. It took me a long time to figure this out. Thanks for all the replies. Each one of them helped me work through this. It turns out that I DID need to upgrade to 8.5 to be able to use the In-Place structure. However, I was forced to make some significant redesigns in order to use the In-Place structures effectively. While this was a significant effort it made senses to keep a consistent architectural design to act on my "object". In the code that was causing me problems I had created subVIs to act on individual parameters of one of my "objects" in a loop. This did indeed cause LabVIEW to make memory allocations (this was brought up in response to my 2nd code post). I think this happened because I was sending both the most top-level cluster along with a unbundled array of objects through the same loop (then rebundling). Now that I have figured out viewing memory allocations I think will be using it in a lot of my future designs. THANKS again for all the input. I would be happy to discuss this problem/solution or similar problems if anyone comes across something similar. -Pete Kudos.

I've been bitten by this before too.Now I use this vi. It ensures there is only ever 1 reference to a queue, you don't need thousands of wires all over your diagram and you can easily access queues from other VIs.

Have you tried the Performance and memory profiler. You can profile the memory and determine which VI sucking up the memory.

You keep getting a reference to Meetbox FIFO but never close it.

QUOTE (normandinf @ Jan 6 2009, 09:55 AM) There are some VIs here on lava too that are more open then the NI ones. They are not OPC but communicate with the Ethernet IP protocol which is what most OPC servers would be using.