Jump to content

dt_openlayer acquisition into qmh style application


Recommended Posts

hi there,
i'm quite new to labview, going to develop a multiple task application of acquiring and logging signals (8ch simultaneously), yet have to add some little features to configuring sw.
I really want to load a single config file, is it binary or xml ot whatever, it does not matter, to set up all that constant wired to the acquisition nodes.
I tryed to configure to my needs the templates, such as the qmh, but i think i don't really understand how does it works...
Also, i'm working with dt openlayers nodes (lv link 3 library) to get the software communicating with the acquisition board (not a national one). Dt acquisition task is similar but do not behave exactly to the common ni DAQ application architecture, no daq express vi available for instance, so i get a little confused.


Well, all that i know is the qmh is a must to get better responsiveness from the UI, while queuing data and send them to separate loops is a good thing to do when acquiring and logging or computing and display simultaneosly..
What i really cannot do is get the acquisition task splitted into the states of the consumer state machine (the consuming loop of the message handler).
I've just placed into the main state "acquire" the whole dt openlayer chain and it does not work, of course!
So after weeks of prototyping i backstep to the starting point and get stuck into a simple producer consumer style acquisition.


Someone can help me how to put things working into the qmh template? It's so a mess!
Thank you in advance

 

procons.llb

Link to comment

hi,
you're right, i realized it makes no sense, since the buffer size is in bytes and samples are... samples!
It seems to work anyway... maybe 100bytes is a too small buffer?

 

anyway, as you can see the Read vi has a lot of wiring before. Can you please suggest me how to group all that stuff into a state machine? Most common cases i've seen around are Initialize, Acquire, Exit...

All vi before Read and his loop, must be considered part of the Initialize case? I tried to split it in a such way, but i cannot be able to rewire accross the cases of the sm.

Quite dumb question i know......

Link to comment
  • 2 weeks later...

hi, I've been trying to build up the top-level vi this week..
Please consider that is a very rude release.
Many controls are just fake controls just to keep things in place.
Anyway, consider the application core is located at the right side of block diagram, you'll be able to see the three loops.

I must proceed adding code to refine the application.
I think the three major issues in this code are:
- will it perform as I assume? I know that dequeuing is such a kind of "destructive" operation, so when the Dacq loop puts its samples into queue, then Display will remove it, so the Logging loop will never write!!
- lack of a structure to grab ui events.
- lack of a convenient ini routine to calibrate the daq board or to tidy up that mess on the left.

I think I got these concepts, but I'm still not able to accomodate these task in a convenient way.

The solution to second problem just would not be a drag&drop of an event structure, I suppose. It is something that involves more top level design, but the examples I've found seems to me quite "unfriendly" to accomodate.
The 3rd problem should be worked out with a state machine, but... It is ok with this queued-style app? Maybe I must add a sort of stand alone SM before the DATX Read vi? Ideas?
Thanks :worshippy:

 

RotarySw.ctl

MainGUI.vi

pannelloCanali.vi

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.