Jump to content

sensor calibration test


Recommended Posts

HI

hope you remember me...i had spoken to you couple of months back...i have few questions regarding my new independent research in school...thought u could help me with it....i tried working on it...and they have asked me to submit this in a week s time so that i would be able to write a report on it.

this is how it goes

basically there are 6 stations each stations perform operations based on a particular time period.For eg. in the research given to me there are 6 stations and there are 3 balls which need to be used while operating the stations.basically what they wanted me to do is these steps

1.after the operator loads the part and prsses pbx(switch) the operation should start

2.the the inductor should energize the capacitor to start at proper time and begin the timer operation for 10 mins,for zero calibration(zero max and zero min in front panel)

when the 10 min timer is running the flash light should work indicating the operator to be at the corresponding station..the operator will adjust the circuit until the 10th minute

if the operator doesnt finish at the 10th minute.Consider the component as fail

wait for 1 minute before the next start is clicked

3.keep the ball in the circuit and start 5 minute timer.

4.At 5th minute adjust to maximum value(span max and span min in front panel) and reset the timers and turn of crx.

i have drawn the front panel and showed the flashing part

basically 0-80% it should be green

80-90% yellow

90-100-flash red

It would be of great help if you could help me out in doing this.

HOPE NORM KIRCHNER CAN HELP ME OUT.

I HAVE ATTACHED THE FRONT PANEL AND BACK END FOR THIS PROGRAM..............THIS IS MY INDEPENDENT RESEARCH WORK IN SCHOOL..I NEED TO SUBMIT THIS IN A WEEK...

PLEASE HELP ME OUT..!

rating_5_mini.gifgender_mystery.pngView Member Profile find_posts.pngView Member Albums friend_remove_small.pngRemove Friend send_pm_small.pngSend Message find_posts.pngFind Member's Topics find_posts.pngFind Member's Posts ipsmenu.register( "post-member-48640", '', 'popmenubutton-new', 'popmenubutton-new-out' );

Link to comment

HI

hope you remember me...i had spoken to you couple of months back...i have few questions regarding my new independent research in school...thought u could help me with it....i tried working on it...and they have asked me to submit this in a week s time so that i would be able to write a report on it.

this is how it goes

basically there are 6 stations each stations perform operations based on a particular time period.For eg. in the research given to me there are 6 stations and there are 3 balls which need to be used while operating the stations.basically what they wanted me to do is these steps

1.after the operator loads the part and prsses pbx(switch) the operation should start

2.the the inductor should energize the capacitor to start at proper time and begin the timer operation for 10 mins,for zero calibration(zero max and zero min in front panel)

when the 10 min timer is running the flash light should work indicating the operator to be at the corresponding station..the operator will adjust the circuit until the 10th minute

if the operator doesnt finish at the 10th minute.Consider the component as fail

wait for 1 minute before the next start is clicked

3.keep the ball in the circuit and start 5 minute timer.

4.At 5th minute adjust to maximum value(span max and span min in front panel) and reset the timers and turn of crx.

i have drawn the front panel and showed the flashing part

basically 0-80% it should be green

80-90% yellow

90-100-flash red

It would be of great help if you could help me out in doing this.

HOPE NORM KIRCHNER CAN HELP ME OUT.

I HAVE ATTACHED THE FRONT PANEL AND BACK END FOR THIS PROGRAM..............THIS IS MY INDEPENDENT RESEARCH WORK IN SCHOOL..I NEED TO SUBMIT THIS IN A WEEK...

Link to comment

QUOTE (kmc @ Oct 31 2008, 01:49 PM)

Ashwin,

You were about ten minutes too early! I just got back to this thread after spending some time in LabVIEW to see your latest post.

Anyway, I think I understand your assignment but don't think that your approach is adequate. I think this is a perfect application for a JKI State Machine (I love the JKI State Machine!!! :worship: ). The only thing that would make me deviate from a JKI State Machine would be the DAQ part; I'd probably need to make some sort of a Producer and use the JKI State Machine as the consumer. Regardless, you have a lot going on and it would be akward to stuff it all into a Sequence Structure (never use 'em myself, 'cept to give myself something to wire to when I'm enforcing data flow on objects w/o inputs). So...

I've made a start at this but don't want to go too far. First of all because it's your assignment and I don't want to either do too much of it for you or lead you down a bad path (more likely?). Secondly, I don't think I have enough information to continue. Please take a look at what I've done and see if it could be developed into a solution to your problem. The "Macro: Initialize" state is where I put the sequence; you can tell what I have in mind by looking there. If you haven't seen the JKI State Machine yet (why not!?!?!?), take a look at the tutorials on their web site. (I think I have the link around here, somewhere... ;) )

There's a bunch left to do; for example, you'd probably want an indicator to prompt the operator on what's expected. The point I left off was simulating the DAQ so I could evaluate the inputs at each station, but that's not too difficult. Let me know if this helps and if I can help further.

Best wishes,

Jim

:question: To the JKI folks & others that are familiar with the JKI State Machine, would you comment on what I've done? I've read the discussions here and on JKI's site, and I've (nearly) finished an application at work based on this (just working on getting Software Quality Assurance approval). I've gotten my feet wet and would like to learn more.

I've added some states to let me sequence through test steps. I've added a "Sequence: Wait" step that causes the program to loop for a specified time so other operations can continue ("Sequence: Wait >> 10" will loop for ten seconds before continuing to the next step). I've added a "Sequence: Wait for button" that will wait until a named button is pressed during a particular test step. "Sequence: Wait for button >> pbx" will loop, holding this place in the sequence, until a button labeled "pbx" is pressed. I'll probably add the option to specify a final state using a command argument. It doesn't handle the event; it just waits until it's pressed. I've put a cluster of control references outside the main loop (so I can set indicators w/o resorting to local variables) and I've added target & elapsed time indicators to the Front Panel.

Do you think I'm OK with these approaches?

Thanks,

Jim

Download File:post-7534-1225478032.zip

Link to comment

QUOTE (jcarmody @ Oct 31 2008, 11:36 AM)

:question: To the JKI folks & others that are familiar with the http://jkisoft.com/state-machine/' rel='nofollow' target="_blank">JKI State Machine, would you comment on what I've done? I've read the discussions here and on JKI's site, and I've (nearly) finished an application at work based on this (just working on getting Software Quality Assurance approval). I've gotten my feet wet and would like to learn more.

I've added some states to let me sequence through test steps. I've added a "Sequence: Wait" step that causes the program to loop for a specified time so other operations can continue ("Sequence: Wait >> 10" will loop for ten seconds before continuing to the next step). I've added a "Sequence: Wait for button" that will wait until a named button is pressed during a particular test step. "Sequence: Wait for button >> pbx" will loop, holding this place in the sequence, until a button labeled "pbx" is pressed. I'll probably add the option to specify a final state using a command argument. It doesn't handle the event; it just waits until it's pressed. I've put a cluster of control references outside the main loop (so I can set indicators w/o resorting to local variables) and I've added target & elapsed time indicators to the Front Panel.

Do you think I'm OK with these approaches?

Thanks,

Jim

Hi Jim,

I reviewed what you did. I have a few comments for various states in your state machine -- a lot of my comments would require re-designing the code so take try to think about them from the perspective of 'design' considerations rather than purely from an implementation perspective:

Macro: Initialize -- While it is possible to use the state arguments for things like cycling through stations, and setting the wait times, it is not really a scalable solution. For example, let's say I want to have 100 stations -- I can't see scaling up Macro: Initialize to handle this situation -- so I'd try to redesign the code to handle N cases

Sequence: Wait -- You may be doing too many things in this frame -- you are waiting, starting to wait and checking if wait is complete -- maybe more frames would make this easier to follow -- for example: Sequence: Start Wait, Sequence: Wait, Sequence: End Wait -- personally I don't like to have a frame do too many things or it gets hard to manage later because you have to remember what the frame is doing in a given context. You could also add a state variable boolean called 'Waiting' that could make the code easier to use in other cases... Also, generally it is a bad practice to have a state send the state machine to 'Idle' because at that point a user may click a button and your 'sequence' will get interrupted -- its better to do some work, when done, go to Idle case

Sequence: Wait for button --This is actually not how the JKI State Machine is intended to check for button presses. You should handle all button presses in the event structure that is in the 'Idle' frame. You should be able to use the Boolean.Value Changed event to know when a button value has changed and the event will return the exact button-- set the boolean to 'Latch when released' to get the same results as what you are doing. There shouldn't be a need to 'find' the button that was pressed. For example , the Exit button (OK) is more appropriately set up.

Sequence: Next station -- Really this is a 'Sequence: Increment station' case. Maybe a better solution is to have a 'Sequence: Set Station' case where the station can be an argument. Why limit yourself to incrementing?

Good luck and hope this helps with future designs for your applications!

Omar

Link to comment

QUOTE (Omar Mussa @ Oct 31 2008, 05:49 PM)

I reviewed what you did. I have a few comments for various states in your state machine

Omar,

Thanks for your help. Would you mind if I asked a question re: Sequence: Wait? I did this in the other program I mentioned because it requires the operator to perform a timed operation not controlled by my software. I didn't want to wait in a state without handling UI events. The sequence needs to continue once the operation completes; how could I handle this without going through Idle? Am I misapplying the JKI State Machine?

I appreciate the time you spent on your response and I'll definitely refer back to your suggestions and take the advice.

Jim

Ashwin,

I hope I didn't hijack your post. Perhaps I misunderstood your original post and you won't need a state machine.

Jim

Link to comment

QUOTE (jcarmody @ Oct 31 2008, 05:03 PM)

There are two parts to this response...

1) One 'feature' of the JKI State Machine is that the empty string case ("") is also the "Idle" case. This means that whenever you finish executing a macro or a series of states, the state machine will return to "Idle"

2) Adding 'Idle' or an empty string in a 'macro', which we can define as any time that you try to queue up multiple events, can and will get you into trouble in a state machine.

Here's a scenario assuming you have the states: Go, Wait, Idle, Stop

Let's assume that 'Go' only happens when 'Wait' completes and that 'Stop' is only reached when the user presses a button that is handled in the 'Idle' frame.

The Wait state contains the following logic: Wait until time elapses -- if time elapsed 'Go' else 'Idle + Wait'

Now -- let's imagine that the 'Wait' time did not elapse (queue contains 'Idle','Wait') -- it is possible for the user to press a stop button which gets handled in the 'Idle' frame due to the event structure, and then the state machine would still proceed to 'Wait' (b/c you queued it already in the 'Idle+Wait' logic) and it is possible that the new 'Wait' state time has now elapsed so the 'GO' frame is reached. This sucks for the user -- they pressed 'Stop' but the state machine still hit a 'Go' frame... now it means you are stuck adding more logic to the 'Stop' frame to handle this scenario -- your code gets uglier, is less scalable and basically you realize that you have all kinds of potential logic problems.

So avoid en queuing "Idle" -- let "Idle" come whenever your state flow ends.

One way to avoid this is to have a 'flag' type of system -- Setup a Boolean called 'Waiting' and set the 'Waiting' flag whenever the user starts to Wait -- then, in the 'Idle' case, use the 'Timeout' frame of the event structure to check if you are waiting -- if you are waiting then do some work, if not, stay Idle.

Here is an example of what I mean:

Set the Waiting flag:

post-5746-1225696763.png?width=400

Check the Waiting flag:

post-5746-1225696782.png?width=400

Initializing and resetting the flag is left for the reader. One thing to consider -- since you have to reset the flag from at least 2 places (usually because the wait time has elapsed or 'Stop' button is pushed) -- it makes sense to have resetting the flag performed in a state (for example, based on your naming conventions -- 'Sequence: Stop Wait').

QUOTE (jcarmody @ Oct 31 2008, 05:03 PM)

I appreciate the time you spent on your response and I'll definitely refer back to your suggestions and take the advice.

Good luck in writing better code! A lot of the time, good code is the result of good design. Entropy pretty much prevents good code from just being 'realized' by accident ;)

Link to comment
  • 2 weeks later...

Thanks a lot omar and Jim ….i really appreciate you guys for patiently replying to my questions…

Hats off to you…Was down with flu…so I wasn't able to check this response for 2 weeks…since I was down

At first…Jim can you resend me the sequencer file…it is asking for "parse state queue_jkl_lib_state _machine.vi file "

I am not sure of what it is..

As far as this program is concerned…there is no question of ELAPSE TIME..In 10 minutes if the operator is not in front of the system...the program needs to stop. the operator needs to set aside the component for an hour to cool down...before starting the program

so basically in idle state the timer runs and flashes in 9 minutes....

Omar,

Can you send me the document you had done…it would be really great..since I am running out of time..i just started this…I wasn't able to do anything for the past 2 weeks since I was done with flu

I really don't have enough time to think..

Folks…..pls help me…

Hope I am not bothering you…I m in a precarious situation.

i would like to thank you guys for viewing my work...

thanks a lot....

regards

Ashwin

QUOTE (Omar Mussa @ Nov 3 2008, 08:29 AM)

There are two parts to this response...

1) One 'feature' of the JKI State Machine is that the empty string case ("") is also the "Idle" case. This means that whenever you finish executing a macro or a series of states, the state machine will return to "Idle"

2) Adding 'Idle' or an empty string in a 'macro', which we can define as any time that you try to queue up multiple events, can and will get you into trouble in a state machine.

Here's a scenario assuming you have the states: Go, Wait, Idle, Stop

Let's assume that 'Go' only happens when 'Wait' completes and that 'Stop' is only reached when the user presses a button that is handled in the 'Idle' frame.

The Wait state contains the following logic: Wait until time elapses -- if time elapsed 'Go' else 'Idle + Wait'

Now -- let's imagine that the 'Wait' time did not elapse (queue contains 'Idle','Wait') -- it is possible for the user to press a stop button which gets handled in the 'Idle' frame due to the event structure, and then the state machine would still proceed to 'Wait' (b/c you queued it already in the 'Idle+Wait' logic) and it is possible that the new 'Wait' state time has now elapsed so the 'GO' frame is reached. This sucks for the user -- they pressed 'Stop' but the state machine still hit a 'Go' frame... now it means you are stuck adding more logic to the 'Stop' frame to handle this scenario -- your code gets uglier, is less scalable and basically you realize that you have all kinds of potential logic problems.

So avoid en queuing "Idle" -- let "Idle" come whenever your state flow ends.

One way to avoid this is to have a 'flag' type of system -- Setup a Boolean called 'Waiting' and set the 'Waiting' flag whenever the user starts to Wait -- then, in the 'Idle' case, use the 'Timeout' frame of the event structure to check if you are waiting -- if you are waiting then do some work, if not, stay Idle.

Here is an example of what I mean:

Set the Waiting flag:

post-5746-1225696763.png?width=400

Check the Waiting flag:

post-5746-1225696782.png?width=400

Initializing and resetting the flag is left for the reader. One thing to consider -- since you have to reset the flag from at least 2 places (usually because the wait time has elapsed or 'Stop' button is pushed) -- it makes sense to have resetting the flag performed in a state (for example, based on your naming conventions -- 'Sequence: Stop Wait').

Good luck in writing better code! A lot of the time, good code is the result of good design. Entropy pretty much prevents good code from just being 'realized' by accident ;)

Link to comment

yes its going to be a tough ask for me....

anyways guys a request

those who have time...pls help me....i m a fresher in labview...this wouldnt be difficult for you guys...

folks...who can help me with this....i would be really greatfull...its just a request...since i am running out of time i m forced to ask u....

hope u understand my situation..

regards

Ashwin

QUOTE (jcarmody @ Nov 12 2008, 06:45 PM)

Attached, but you should really install the entire package from JKI.

From the comment on the VIs front panel:

This might be tough...

Jim

Link to comment

Ashwin, have a look at the guidelines for this forum. Moreover learn to ask questions the smart way.

I read through the topic, only the first post has a question about code, and has little no interpunction.

You have not added any code, we have no idea what actually is your problem and current state of your coding.

All these things together hold me back in helping you. LAVA is not a LabVIEW solution center.

Ton

Now where is the good coffee?

Link to comment

I AM SORRY I DINT MEAN TO ASK YOU FOR A FULL SOLUTION CENTER

I Would like to explain what i have done first so that It would be easier for you to help me...

1. As you see there are 6 STATIONS.Each Stations perform various Tasks.Basically THE MAIN IDEA is to MONITOR THESE STATIONS.

THERE ARE STEPS TO MONITOR STATIONS

1.AT FIRST WHEN OPERATOR LOADS THE PART THE PBX(switch) WILL GET ENERGIZED.

2.10 MINUTE TIMER IS SWITCHED ON AT THIS STAGE.AT 9TH MINUTE THE TIMER STARTS FLASHING (THAT INDICATES THE OPERATOR SHOULD BE AT THE STATION)

3.IF THE OPERATOR IS NOT THERE AT 10 TH MINUTE U GET AS FAIL(THE PART SHOULD BE SET ASIDE FOR 1 HR TO COOL)...THATS THE REASON WHY THE FLASHING PART HAS BEEN KEPT

4.THERE IS A BALL KEPT ON THE PART...AS SOON AS THE BALL IS KEPT...ANOTHER 5 MINUTE TIMER IS SWITCHED ON...AT THAT TIME THE OPERATOR WILL NOTE DOWN FEW VALUES

5.AT 5TH MINUTE ADJUST TO MAX VALUE,OPERATOR REMOVES PART AND RESET THE TIMER AND TURN OFF THE SWITCH

IF YOU SEE WHAT I HAVE DONE IN TIMER

U SEE THAT 0-20-40-60-80-100(THE ONE JUST ABOVE READY) THAT IS A INDICATION

0-80---GREEN

80-90---YELLOW

AT 90---FLASHING RED...I HAVE WORKED ON FLASHING RED...

FEW FOLKS HAD TOLD ME TO USE A JKI SYSTEM...I AM TRYING TO READ THAT AS OF NOW...I WOULD REALLY APPRECIATE IF YOU COULD HELP ME IN THIS...

I AM PUTTING MY BEST EFFORT AS OF NOW...

I HAVE BEEN BREAKING MY HEAD FOR A REASON... :headbang: I AM EXTREMELY SORRY FOLKS...

I HOPE TO HEAR FROM YOU SOON...

REGARDS

ASHWIN.... :rolleyes:

QUOTE (Ton @ Nov 12 2008, 09:00 PM)

Ashwin, have a look at the guidelines for this forum. Moreover learn to ask questions the smart way.

I read through the topic, only the first post has a question about code, and has little no interpunction.

You have not added any code, we have no idea what actually is your problem and current state of your coding.

All these things together hold me back in helping you. LAVA is not a LabVIEW solution center.

Ton

Now where is the good coffee?

Link to comment

QUOTE (Ton @ Nov 12 2008, 09:00 PM)

Interpunction does not mean all in capitals, write sentences and questions, take the time to write a question.

Write it in notepad (not Word or an HTML editor), save it. Wait half an hour, open and reread.

Do you have clear questions, if so post them.

QUOTE

The code posted in the first post is two weeks old, what is the current state of your code?

QUOTE (kmc @ Nov 13 2008, 02:31 PM)

I AM SORRY I DINT MEAN TO ASK YOU FOR A FULL SOLUTION CENTER

I Would like to explain what i have done first so that It would be easier for you to help me...

1. As you see there are
6 STATIONS
.Each Stations perform various Tasks.Basically
THE MAIN IDEA is to MONITOR THESE STATIONS.

Just start with one station, duplication of code is easy.

QUOTE

THERE ARE STEPS TO MONITOR STATIONS

1.AT FIRST WHEN OPERATOR LOADS THE PART THE PBX(switch) WILL GET ENERGIZED.

2.10 MINUTE TIMER IS SWITCHED ON AT THIS STAGE.AT 9TH MINUTE THE TIMER STARTS FLASHING (THAT INDICATES THE OPERATOR SHOULD BE AT THE STATION)

3.IF THE OPERATOR IS NOT THERE AT 10 TH MINUTE U GET AS FAIL(THE PART SHOULD BE SET ASIDE FOR 1 HR TO COOL)...THATS THE REASON WHY THE FLASHING PART HAS BEEN KEPT

4.THERE IS A BALL KEPT ON THE PART...AS SOON AS THE BALL IS KEPT...ANOTHER 5 MINUTE TIMER IS SWITCHED ON...AT THAT TIME THE OPERATOR WILL NOTE DOWN FEW VALUES

5.AT 5TH MINUTE ADJUST TO MAX VALUE,OPERATOR REMOVES PART AND RESET THE TIMER AND TURN OFF THE SWITCH

I HAVE BEEN BREAKING MY HEAD FOR A REASON... :headbang: I AM EXTREMELY SORRY FOLKS...

Go over the points you have posted step by step.

Post the current code with references to every point mentioned here.

Good luck

Ton

Link to comment

thanks ton for your reply

omar,

can you send me the labview file which u had done ??? the one which had the sequence wait ???

regards

Ashwin

QUOTE (Omar Mussa @ Nov 3 2008, 08:29 AM)

There are two parts to this response...

1) One 'feature' of the JKI State Machine is that the empty string case ("") is also the "Idle" case. This means that whenever you finish executing a macro or a series of states, the state machine will return to "Idle"

2) Adding 'Idle' or an empty string in a 'macro', which we can define as any time that you try to queue up multiple events, can and will get you into trouble in a state machine.

Here's a scenario assuming you have the states: Go, Wait, Idle, Stop

Let's assume that 'Go' only happens when 'Wait' completes and that 'Stop' is only reached when the user presses a button that is handled in the 'Idle' frame.

The Wait state contains the following logic: Wait until time elapses -- if time elapsed 'Go' else 'Idle + Wait'

Now -- let's imagine that the 'Wait' time did not elapse (queue contains 'Idle','Wait') -- it is possible for the user to press a stop button which gets handled in the 'Idle' frame due to the event structure, and then the state machine would still proceed to 'Wait' (b/c you queued it already in the 'Idle+Wait' logic) and it is possible that the new 'Wait' state time has now elapsed so the 'GO' frame is reached. This sucks for the user -- they pressed 'Stop' but the state machine still hit a 'Go' frame... now it means you are stuck adding more logic to the 'Stop' frame to handle this scenario -- your code gets uglier, is less scalable and basically you realize that you have all kinds of potential logic problems.

So avoid en queuing "Idle" -- let "Idle" come whenever your state flow ends.

One way to avoid this is to have a 'flag' type of system -- Setup a Boolean called 'Waiting' and set the 'Waiting' flag whenever the user starts to Wait -- then, in the 'Idle' case, use the 'Timeout' frame of the event structure to check if you are waiting -- if you are waiting then do some work, if not, stay Idle.

Here is an example of what I mean:

Set the Waiting flag:

post-5746-1225696763.png?width=400

Check the Waiting flag:

post-5746-1225696782.png?width=400

Initializing and resetting the flag is left for the reader. One thing to consider -- since you have to reset the flag from at least 2 places (usually because the wait time has elapsed or 'Stop' button is pushed) -- it makes sense to have resetting the flag performed in a state (for example, based on your naming conventions -- 'Sequence: Stop Wait').

Good luck in writing better code! A lot of the time, good code is the result of good design. Entropy pretty much prevents good code from just being 'realized' by accident ;)

Link to comment

QUOTE (kmc @ Nov 13 2008, 11:27 AM)

omar,

can you send me the labview file which u had done ??? the one which had the sequence wait ???

I don't have them on my computer any more. You should be able to easily re-create them from the screenshots, they took < 5 min to make so I'll leave it to you to redo the work.

Omar

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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