advice on finishing touches for circuit.

[GerdW]

Hello Mark,

I have a question on your LV8 example, as I never worked with variants so far:
In the analyze state are 3 comparisons (two times "less than or equal 49.5" and "greater or equal 50.5"). They get their signal as variant created by making a 2D array from a DBL 1d array, choosing the first row of data (should be the 1d array as before) and transforming to variant. Why do you use all these steps?
Next question for my understanding: the express vi's do the comparison on an array of data (in the form of an variant) but the indicators are just scalar booleans. What do the indicators display? Just the first element of the array or do they show the result of an "AND array elements" (or "OR array elements")?

Isn't it much easier to do the comparison directly using the functins from the comparison palette?

TIA

Message Edited by GerdW on 04-03-2006 05:02 PM

[MarkLe]

Hey Guys,

Attached is the code from before HOPEFULLY working for LV 7.1 now (it works OK on my machine)! Don't know what was wrong with my previous save for previous version, sorry!!

Gerd, I just copied and pasted lanoob's original code, I'm not 100% sure what it's up to either, I don't know the whole ins and outs of the harmonic analysis VI. Regarding the Express VIs, they use the Dynamic Data type (the dark blue wiring) which, as you've gathered, adapts to do the operations on however many channels are contained within the set.

I think if you connect the DDT to a boolean indicator, it becomes TRUE if any of the channels is TRUE, it is only FALSE if all of the channels status is FALSE.

Give me a shout tomorrow if you've got any further questions (had a busy afternoon!)

Cheers,

Mark

[labnoob]

hi, mark.

im liking your code. changing some things ever so slightly. mainly due to me not fully explaing what needed. all in all though it is a great basis for what i nede to do, and for that i thank you. did you design the state diagram with the state diagram toolkit, or just manually. im just wondering what the best way of implenting those (i think they are called) "refnums" ( the lblue bordered boxes holding the states.

cheers

G

[MarkLe]

Hi lanoob,

Thanks for your feedback, glad you’re getting on well with the code. We’re trying to teach the state machine architecture as early on as possible in LabVIEW Basics courses as it makes customers’ code much easier to debug, maintain and expand in the future.

The architecture is actually shipped as one of the templates with LabVIEW – you can get a ‘blank’ architecture either by clicking on the VI from template link on the splash screen for LabVIEW 8 – or by selecting the New option from the File Menu. This will give you a tree structure of templates available, the state machine is under the From Template-Frameworks-Design Patterns branch of the tree.

The state diagram toolkit CAN be used to setup a state machine architecture, if you wish.

The constant that controls the state transitions is known as an enumerated constant, as you’ll have seen it has each state defined by name (it can be found under the numeric palette). You can edit the states, but to make sure each constant changes when one is edited, you have to define the constant as a type definition. When you try and edit the states from the template (or my example) you need to right click on the constant and select Open Type Def. This will bring up an editor window with the constant on the front panel. If you right-click on the constant and select Edit Items, this will bring up a screen which allows you to change, add and edit the defined ‘states’. When you’ve finished, drop down the File menu, and select Apply Changes to update ALL of the constants on the main architecture. Then you need to save the control using the save options under the file menu (for this is what it is, an edited control) and keep it in the same directory as the vi.

Hope all this helps. Good Luck with the rest of your project.

Mark

[labnoob]

hi mark. i have changed the aquisition bit so that it now encorporates the example "Cont Acq&Graph Voltage-Analog SW Trigger.vi" i need this for the triggers. anyway, i have the follwoing problems. perhaps ig you have time you would be able to exlpeni why they have manifested theirselfs.

1. intially there is a 10 seconds delay upon pressing run. i understand this will be to do with the time elapsed vi. but unsure how to ammend this.

2. circuit only seems to run correctyl the firast time. i.e reads a 1000 samples, displays it shorty, timer counts up, then at 10 seconds it starts again, however it isnt sampling anything again, it just restarts the counter!



any suggestions? have i wired it correctly.

thanks again.

Griogair

[labnoob]

actually, the unwanted initial delay doesnt occur when i try it on this uni Pc (weird), only on my home PC. however, other problem still occurs.

i ammened a couple of things, thus a attached an upadted version. cheers .
cheers. m8.

[MarkLe]

Hi Griogair,

I haven't had time to have a long look at this yet, but what I think may be going on is that after your "time check" state you're sending  the state machine back into the "Initialise" state. This is trying to generate a new task, while the original one is still active (I wrote the code only to stop and clear the task once the whole state machine architecture has exited - you'll see the DAQmx VIs to do this (stop and clear task) are outside of the main while loop).

If you want it to re-make the task every time you go for an acquisition, I'd suggest stopping and clearing the task within the "Acquire" panel (after you've done the acquisition).

If you don't think the properties of the task will change between acquisitons, I'd leave the code as it is, keep the task running and just send the state machine back into the "Acquire" state after the time check, rather than the "Initialize" state. 

Hope this helps, like I say I haven't checked it fully yet but this would be my gut instinct as to what is going on!

Please let me know how you get on!

Mark

[labnoob]

"

If you don't think the properties of the task will change between acquisitons, I'd leave the code as it is, keep the task running and just send the state machine back into the "Acquire" state after the time check, rather than the "Initialize" state. "

ye sorry for hogging your precious time mate. that works kind off. im was just a tad confused as when in run mode (using your advice above), the  acquire section  kept  running forever, as in  it wasnt just taking 1000 samples, stoping then  passing it  to the "save" frame, pausing for 10 seconds, then restarting as i would have expected. instead, it contnued to aquire whilst it was meant to be in pause mode (i,e 10 seconds). it would however, save 1000 samples after 10 seconds, but the trigering is all to pot. and its fundamental that i collect on the zero crossing, or a few presamples before.

any ideas .


ive kept the code the way it as as sugested above.

[MarkLe]

Hi G,

Don't worry about my time, just worried I hadn't really checked the code I posted this morning.

I think what's going on with the acquisition is that it's set up in continuous mode, so once the acquisition is started it will continue sampling data sets even when the read data vi isn't called. If you need it to just read a burst them idle, set the sample mode in the sample clock configuration to Finite samples rather than Continuous samples and see if that solves it for you.

Let me know how you get on!

Mark

[labnoob]

we're getting there!! lol

finte sorts out the burst issue, however, after the 10 second interval, it doesnt seem to  aquire any more data, but it still  runs through the  timer and save parts. hmmm 😕