Jump to content

electro_

Members
  • Posts

    14
  • Joined

  • Last visited

  • Days Won

    1

electro_ last won the day on February 25 2016

electro_ had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Columbia, SC
  • Interests
    Electronics, PCB development, software development.

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since
    2000

electro_'s Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. 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
  2. I beginning to think they ain't paying me enough for this gig!
  3. 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.
  4. 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?
  5. 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
  6. 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
  7. DANG! Put the code up there and everybody run like cockroaches from Raid. Still working the problem.
  8. Sorry, where the timer in question is. (DAQ while Loop)
  9. 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"
  10. 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
  11. 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.
  12. 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
  13. 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 First time in all four are ok 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. continues to run this pattern from second cycle on. 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.
  14. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.