LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

MOKE Program Initialization Function

Solved!
Go to solution

Hi,

 

I'm currently working as an intern at Drexel University, and I'm currently working with a program that operates a Magneto-Optic Kerr Effect Magnetometery setup. The program communicates with a series of instruments (specifically a power supply, gaussmeter, and sourcemeter as well as some equiment to gather the data) to operate an electromagnet that sweeps a field back and forth across a sample to obtain a magnetic hysteresis loop for the sample. To calibrate the instrument, we run a demagnetization program (a separate LabVIEW program), which brings the remanent magnetization down to approximately 3-5 Oe, which is acceptable. However, upon initializing the main program (attached) by clicking the run arrow in the toolbar, the field immediately drops to approximately -20 Oe. This occurs before we set the parameters of the front panel and press the "Run" button in the VI itself. Can anyone help me identify where in the program this is initialized (if it is an issue with the program)? The electromagnet is controlled by the power supply, so it's likely that the program sets the power supply to a certain voltage as opposed to the magnet being set to a certain field strength. I am extremely inexperienced with LabVIEW, so screenshots as appropriate would be extremely helpful.

 

Thank you very much for your help,

 

AF

 

EDIT: The password to the block diagram is "nosteven"

0 Kudos
Message 1 of 7
(2,530 Views)

In answer to your question: No, I can't help you.

 

The block diagram is locked.

 

Mike...

 

PS: The front panel does look very nice though...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 7
(2,526 Views)

My apologies, the password to the block diagram is "nosteven"

0 Kudos
Message 3 of 7
(2,522 Views)

Jeeze Louise!

 

Hope you don't take this personally, but that code almost made my eyes bleed.

 

Seriously though, there is very little in that code that is recoverable, but to your specific problem: Execution order in LV is dependent upon data availability. This is what we mean when we say LV is a dataflow language. In short, any node (VI, structure, etc) that has all it's input satisfied will start executing.

 

The data coming from the loop where the run button is located (this is really bad design) will keep the main loop from executing until the run button is pressed. The problem is that there is a whole bunch of initialization that happens in parallel with the loop containing the run button. Because their inputs are immediately satisfied they will begin executing in parallel with the run button loop. That is very likely what is causing your problem.

 

What exactly, is the scope of the work you are being tasked with doing?

 

Mike...

 

Otrher issues of note:

  • No subVIs
  • An enumeration that is simply the numbers 0-4
  • Sequence structures being used
  • The whole "run-button-in-a-separate-loop" thing

 


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 4 of 7
(2,510 Views)

No offense taken! The person who wrote the code graduated from drexel a couple of years ago; I share your pain.

 

My personal task is to run our magnetometer and analyze the data, as well as troubleshoot any issues with the program (or the physical setup) that I come across. Recently, I found out that there are numerous issues with this program that impact our data. The last person who had this job attempted to fix some of these issues with some assistance from the LV forums, but from my understanding that amounted to a couple of duplicate posts on the forums with no solution. 

 

I'm not sure how much detail you wanted me to go into, so I'll briefly explain each issue I've been tasked with fixing in addition to the initialization problems:

 

1) The program creates a hysteresis loop by increasing the field strength of the electromagnet in [step size] increments until it reaches [amplitude], then decreasing the field until it reaches the negative amplitude value, then increasing the field until it reaches zero. After a set number of loops, the program averages all of the loops together to produce a large average loop. In between each step, however, the field drops to 0 for a moment before going up to the next value. This is extremely undesirable, as some samples will respond to this momentary drop in field strength.

 

2) At the end of each loop, the last few data points deviate significantly from the rest. None of the measument tools that we have suggest that this data is real, which leads me to believe that the program is creating these points. From my understanding, either the program is attempting to close each loop (and doing a poor job), or the data is being impacted by the fact that not every loop has the same number of datapoints.

 

My only coding experience lies in MATLAB and Python (this job wasn't supposed to require any LabVIEW experience until the program started acting up; I'm trying to learn LV now), so I haven't been able to fix anything myself.

 

Thanks for your advice so far, and I hope that the information I provided helps.

 

-AF

0 Kudos
Message 5 of 7
(2,498 Views)
Solution
Accepted by topic author drexelMOKE

Ok, first thing is that you need to get some training. There are free online tutorials available that will get you pointed in the right direction. In terms of your previous experience, neither will be especially helpful in this endeavor. Matlab because it isn't a strongly-typed language and Python because it is a text-based control-flow programming environment. Both languages address problem solving in a way that runs contrary to how you think about problems in LV.

 

In general, I would recommend (and I realize that some of this explaination might not mean anything to you right now, but it will provide an "aim-point" at least) an event driven structure that implements a state machine. My sense is that much of what will be the final state machine already exists in the logic using the enumeration. The first thing to do is to change the enumeration to a type definition, replace it everywhere it occurs and then go through the states to give the enumeration labels that are descriptive of what is happening in that state. Also add a new state called "Initialize" to do the stuff that is currently outside the loop.

 

In terms of the program structure itself, you want a while loop with an event structure inside it. The three events you will need are a timeout event (this is where the state machine will go), a run button value change event to enable the timeout, and a stop button (new) value change event to stop the program. As it is written now it only runs one test and then stops. The way to enable and disable the timeout is by changing the timeout value passed to it. -1 disables the event, any positive value sets the timeout to that number of milliseconds.

 

For the modularization, go through the code and start looking for bits of code that are duplicated, and put them into subVIs.

 

That will get you started. Post new code as you produce it and we will do our best in guiding you along the way.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 6 of 7
(2,487 Views)

Thanks a lot for your help! I'm working through some tutorials right now, and once I feel comfortable with LV I'll be sure to post my code as I work on it.

 

-AF

0 Kudos
Message 7 of 7
(2,442 Views)