Elapsed time

[electro_]

Having problems with an elapsed time.vi. When I start the vi all is well, but when I leave the case structure I'm in and return the vi first puts out the total time elapsed from the point it was started. Anything I've tried ends up in a loop. I need to good way dump the running memory when the program returns to the case prior to being used.

Thanks for any help

Steve

 

Attached is the problem area

[hooovahh]

Uh...what?  The elapsed timer is intended to count up to a certain value, then it gets reset, and then it counts back up again and again.  There is some optional inputs that can change this behavior but normally this is how it works.

 

So if you are using the elapsed timer for a set of things, then stop, and you want to start the timer again, you should give it a True on the Reset input, the first time you are coming back into your loop.  I've usually done this by using the Equal to Zero function, and wire it to the iteration counter of a for or while loop.  Then it will be True the first time that loop starts which will reset the timer.

[electro_]

Uh...what? Is a strange way to start any inter webs conversation. Guess I'll have to work with it huh? I know exactly what an elapsed timer does and how it functions, not being touchy here, but look at the posted code, I have auto reset set to true. I tried reset, set to true, a variable that is set to true in the case structure it goes to, Globals set to true in the case structure it goes to, and I still have the same problem.  The timer is in a nested case structure inside of a while loop and doesn't leave the loop till the exit button is pressed by the user. When it returns to the case structure I posted the very first output is fine and the program behaves the way I want it to. When the next test cycle starts the total time in memory from the previous cycle to that point is what outputs from the elapsed timer first (even with reset or auto reset being tied true) and is greater than time from the unbundle cluster.

     This controls 4 progress bars for the user to see. Each progress bar represents the time a tool is tested at a given torque till it has expired and moved to the next time. The times are 8 sec, 10, 15, and 5 sec perspectively.   

           Some of the behaviors are  

1. First time in all four are ok
2. Second cycle and beyond time is greater than timer output and first progress bar time is skipped  and goes immediately to second timer and executes the next three fine.
3. continues to run this pattern from second cycle on.
4. Also this is added code to an existing program.

Not meaning to appear rude AND I do appreciate any help and I'd like to figure this out.

 

Steve

PS I'd send the code but not sure what size limitations are.

[hooovahh]

Sorry if my mannerisms seem strange, replace my opening sentence with "What you are trying to do is not clear to me, could you explain it in another way that is clearer, or post simple demo code that exhibits the behavior".

 

Yes I see you are resetting the timer, but couldn't tell from the picture if you have True wired to the Auto Reset, or the Reset, posting code instead of pictures in these cases makes it clearer.

 

Attached is a quick example of what I was talking about.  Where there is a loop that runs, and when you click a button two waits are done, one for 2 seconds one for 3 using the elapsed timer, resetting it between each call.  This also resets when you first come into the wait so the timer should work as expected where it always counts up to 2, then 3.  Notice that the reset only happens when the inner while loop has an iteration of 0, and then isn't reset until the next timer starts.  Without this you will get strange behavior because multiple seconds will have gone between pressing the button a second time, so the first wait (the 2 second one) will be completed immediately.  I suspect this is what you are seeing.

 

I also don't intend on being rude.

[electro_]

Sorry I read into that wrong, I'm trying to attach a video of the running program so you can see what's going on, and let me try to put the code in you sent and see if I can get it to work. I have to get out of my building to send this video from a cell and it's lunch, I'll get the video up after lunch

 

Thanks again,

Steve

[ShaunR]

Is your VI shared, re-entrant?

[electro_]

It is shared and the code I posted is in the DAQ loop section of a typical state machine. I did turn on Re-entrant in vi properties per an article I read a week ago on this problem, and I tried to incorporate hooovahh code into mine and it does reset the timer but I have to bring in everything around it in the loop. At the moment I'm trying to rework it using the DAQ loop I'm in that hooovahh suggested but I keep running into issues with out side calls to turn on and off air to run the tool. Your typical debugging stuff. I am much closer to an answer though. 

    For what it's worth I'm not a Labview Architect but I've been working with Labview, C, and machine code for the better part of 15 years and have gotten really good at it, taken quite a few classes with Six Clear. Oh yeah and I have NO engineering support, I'm the only one that can work the code.

I do appreciate all the help you guys through out there,

Steve 

PS Still trying get the video on this I took and better pictures of the code layout.

[ShaunR]

It is shared and the code I posted is in the DAQ loop section of a typical state machine. I did turn on Re-entrant in vi properties per an article I read a week ago on this problem, and I tried to incorporate hooovahh code into mine and it does reset the timer but I have to bring in everything around it in the loop. At the moment I'm trying to rework it using the DAQ loop I'm in that hooovahh suggested but I keep running into issues with out side calls to turn on and off air to run the tool. Your typical debugging stuff. I am much closer to an answer though. 

    For what it's worth I'm not a Labview Architect but I've been working with Labview, C, and machine code for the better part of 15 years and have gotten really good at it, taken quite a few classes with Six Clear. Oh yeah and I have NO engineering support, I'm the only one that can work the code.

I do appreciate all the help you guys through out there,

Steve 

PS Still trying get the video on this I took and better pictures of the code layout.

 

Change the VIs reentrancy to  be "Pre-allocated", rather than "shared", and see if it resolves your issue.

 

The elapsed timer VI is one of those that relies on an uninitialised shift register and is set to pre-allocated so it must be called from either another pre-allocated clone or from a normal VI.

[electro_]

Here is more of the main vi and I'm sure how to get the entire thing on here? Not sure program wise what I can post that would help you see the problem better.

Steve

[hooovahh]

Here is more of the main vi and I'm sure how to get the entire thing on here? Not sure program wise what I can post that would help you see the problem better.

Ideally the whole project, all source, all libraries, all dependencies, with instructions on how to reproduce the issue.  Usually this is done by zipping up all source, then uploading that zip in a post.  For most this is not practical so some example code that exhibits the issue would work.  Posting pictures is almost useless, some stuff can be understood from it but not things like what is going on in subVIs, how VIs are configured, or how express VIs are configured just to name a few down sides.

 

If you do attach images, it is recommended you post snippets which are PNG files with embedded code in them.  They only contain that VI so all external dependencies will still be missing.  

 

http://www.ni.com/tutorial/9330/en/

[electro_]

Ok hooovahh I have the whole program in snippet.

  

PS Not sure why but it un-checked a lot of the inputs from view as icon? And the DAQ case structure is "Timed Test Running"

[electro_]

Sorry, where the timer in question is. (DAQ while Loop)

[electro_]

DANG! Put the code up there and everybody run like cockroaches from Raid.  Still working the problem.

[hooovahh]

DANG! Put the code up there and everybody run like cockroaches from Raid.  Still working the problem.

It's only been a day since you posted the code, but that being said I opened it...

 

Please don't take this the wrong way but some refactoring looks in order.  If you have to scroll in more than one direction, then your code is probably not modular, scaleable, reusable, or extensible enough.  It is difficult to follow and understand, and therefor difficult to troubleshoot and recommend a fix.

[electro_]

Sorry we got off on the wrong foot I've been wiped out with something running around here for the past few days and am finally past it. I've developed pretty thick skin over the years, and I'm a big boy so I can take it. I inherited this problem from a long line of "Hey can you add this to it...." so the code reflects the I have to have it yesterday mentality. I've been hacking out a lot of really bad code to get it stable, as far as refactoring, I could use some help on that. I'm trying to get it running right and then go from there. There were quite a few areas where it looks like something was started and then in mid flight they disabled it????  Sorry was being a little impatient there. Being new to getting you the information you need I may have over did it a little. I rarely work outside of the computer being used for the tester it is designed for so transferring information you would need is pretty new to me.

    Alright, what do I need to do so you have it modular, scalable, reusable, and extensible? As far as difficult to follow... brother I'm all over that one! AND yes I do completely understand it is difficult to troubleshoot and recommend a fix for. I will put patients at the top of the priority list for this. I did find something interesting yesterday, when the case that the Elapsed Timer is in runs to the end of each count, the end of the iteration clock always has .120007 seconds on its output and not just 0.  My concern is that if it is 0 it won't work at all.

Enough for now let me know what you need,

Steve

[ShaunR]

Here is more of the main vi and I'm sure how to get the entire thing on here? Not sure program wise what I can post that would help you see the problem better.

SteveMain VI Properties.jpgMain Diagram.jpg

Cockroach #1,545,432,323 reporting in!

 

Your VI is not shared re-entrant so you are not suffering from the problem I was outlining. It's an application issue rather than a sneaky LabVIEW issue.

Edited February 25, 2016 by ShaunR

[electro_]

 Damn glad to see the Raid didn't get you Shaun. I was pretty sure it was the code and not Labview. Yesterday I dug pretty deep on the problem and saw a few things. The biggest one was a timing issue. When the timer reaches end of the first count, it gets from a table, it goes to two other cases and returns in 80ms (which is less than the next count from the table). When it reaches the last count from the table it is directed to a case that has a delay timer and waits there for 25sec (cool down time, don't want to burn up the tool before we get data out of it) then to a case that waits for the tool spin up (2sec), for those keeping score that's 25+2+80ms (moving between cases) which is 27.8sec. when it comes back to the "test running" case, the Elapse Timer 7 is still running and the first output is 27.9sec which greater than the 8sec the table calls for on the first count.

So that's where I am,

Steve

[electro_]

Any Idea why at the last cycle the output is 0.120007sec and the "time has elapsed" true false out is held true till the next cycle starts?

[JKSH]

I inherited this problem from a long line of "Hey can you add this to it...." so the code reflects the I have to have it yesterday mentality.

 

Sometimes, users ask for things without fully understanding the complexity involved.

 

If you're asked, "Hey can you add this to it..." you can reply, "Yes, and it will take X days and/or Y dollars to do it properly". If they pressure you to do it faster/cheaper, you need to make a judgement call -- should you should do as they asked, or should you try to change their mind? If it's not truly urgent, you could explain that shortcuts will jeopardize the quality of the code and make it harder to make improvements in the future.

 

 

I've been hacking out a lot of really bad code to get it stable, as far as refactoring, I could use some help on that. I'm trying to get it running right and then go from there. There were quite a few areas where it looks like something was started and then in mid flight they disabled it????

 

Cleaning up your code could make it easier to get it stable, simply because the code becomes easier for you to follow. The easiest starting point it to identify and delete code that doesn't do anything useful. I would get rid of those disabled/abandoned bits.

 

Another example: The pink wire at the bottom of the DAQ loop is unused and should be deleted.

 

 

Alright, what do I need to do so you have it modular, scalable, reusable, and extensible?

 

Here's a starting point:

• Better Separation of Concerns. One component should focus on doing only one thing, and other components should not share its job. This makes it easier to reuse the component in other projects. It also makes it easier to identify where a change needs to be made when updating the code. For example, the DAQ loop should indeed be in charge of doing DAQ, but it shouldn't be responsible for reading/writing settings files.

 

• Avoid duplicating code. For example, in the DAQ loop, "Safe Stop" and "Timed Safe Stop" have exactly the same logic. See if you can find a way to merge them.

 

• More comments within the code, to describe what's going on. What do the various boolean wires mean?

 

 

Any Idea why at the last cycle the output is 0.120007sec and the "time has elapsed" true false out is held true till the next cycle starts?

 

I'm not sure what you're asking, and I can't run your code. I recommend creating a new VI, put an Elapsed Time express VI in a loop, and experimenting with its inputs and outputs. See post #4 (Hooovah posted some sample code). Reading http://zone.ni.com/reference/en-XX/help/371361M-01/lvexpress/elapsed_time/ could help too.

[electro_]

Thanks JKSH

     Nothing sends them packing faster than cost and time. I'll be using those in the future. I've spent weeks at a time cleaning up the code and I know I'm no where close to where it should be, wished I had a picture of the first time I opened the code, I didn't know whether to cry or run for my life. I'm still here so you know which one I did. As far as the pink wire at the bottom it updates a boolean button in the over thrust case of the DAQ loop, if it's the same one I think your talking about.

    I'll read the Separation of Concerns when I get the chance and one of my documenting task I have is to put in descriptors for more readability.

 

The last one was the basic problem itself, 

"When the timer (Elapsed Time 7) reaches end of the first count, (there are 4 progress bars that are being updated one after the other) it gets from a table, (First is 8sec) it goes to two other cases and returns in 80ms (which is less than the next count from the table). When it reaches the last count from the table it is directed to a case that has a delay timer and waits there for 25sec (cool down time, don't want to burn up the tool before we get data out of it) then to a case that waits for the tool spin up (2sec), for those keeping score that's 25+2+80ms (moving between cases) which is 27.8sec. When it comes back to the "test running" case, the "Elapse Timer 7" is still running and the first output is 27.9sec which greater than the 8sec the table calls for on the first count." This causes it to skip the first progress bar of 8 sec from the table and starts the next one.

hooovahh code did work but also created a lot of timing issues.

    It did, as you pointed out, make me start looking at how to control the auto reset and reset so this issue will be solved.  

[ShaunR]

Sometimes, users ask for things without fully understanding the complexity involved.

 

If you're asked, "Hey can you add this to it..." you can reply, "Yes, and it will take X days and/or Y dollars to do it properly". If they pressure you to do it faster/cheaper, you need to make a judgement call -- should you should do as they asked, or should you try to change their mind? If it's not truly urgent, you could explain that shortcuts will jeopardize the quality of the code and make it harder to make improvements in the future.

 

Good god no

That's a sure fire way to allow managers to think "1/2 his timescales because he always over estimates" and will get  you working weekends as the deadline approaches while they picnic with their families!

 

There is no such thing as "properly" in management - only working or not.

It takes this long, costs this amount of money, period! (because you never guess or estimate, you always calculate to ensure the project is on-time and on-budget, right? ) If you are pressured, you supply a list of features and ask them to cross off the ones they don't really need or want and you will recalculate. Alternatively, they can give you a deadline and you will supply them with the features that can be achieved within it.

 

You want the reputation that your first plan is considered, calculated, already optimized and accurate for an on-time and on-budget delivery and there is no point in questioning it if they need everything you have listed.

[electro_]

I beginning to think they ain't paying me enough for this gig!

[JKSH]

There is no such thing as "properly" in management - only working or not.

It takes this long, costs this amount of money, period! (because you never guess or estimate, you always calculate to ensure the project is on-time and on-budget, right? ) If you are pressured, you supply a list of features and ask them to cross off the ones they don't really need or want and you will recalculate. Alternatively, they can give you a deadline and you will supply them with the features that can be achieved within it.

 

You want the reputation that your first plan is considered, calculated, already optimized and accurate for an on-time and on-budget delivery and there is no point in questioning it if they need everything you have listed.

 

Mm, you're right. Requirements prioritisation and firm, systematic management is the way to go.

 

I've been spoilt -- our manager used to do the same work as so he defers to us for timeline estimates calculations, and most of our customers have been reasonable with their expectations

[electro_]

Thanks guys for all the help,

     I figured the problem with the example code hooovahh posted. When I used his code I put the Elapsed Timer into a case to control the reset. I put boolean global variables in and ran the results to a shift register, my problem all along has been I didn't wire the change to the variable to the shift register.

Problem solved, with all of your help, thanks again,

Steve Caldwell

Apex Tool Group

Lexington, SC