pitermann

thanks for your reply. I'm aware of "lock front panel" checkbox on each event case editor, but the program is not affected by this. And it shouldn't, of course. The event structure cases are merely control cases, I've just put inside an enum constant to properly address de main SM. I forgot saying the "time consuming" task is into a SM's state, not into an ES case. Is disabling buttons the only way to keep them out of firing unwanted events? It'll be quite a wire jam to manage buttons gray out. What about saying something like this: "hey... stop listening to events now..."

hello lavas, I developed the entire application as a standard state machine, which has an "Idle" state with an event structure inside. The event structure captures UI buttons value change events. My aim is to capture ui events *ONLY* when the main state machine is waiting, that's all. In other words, if tasks have been completed and the state machine returns to the idle state, the user is allowed to perform another task by clicking on its button. However, when I start a task, the SM correctly switches from Idle to the correct state (i.e. DAQ INITIALIZE), but if I intentionally push a again a button, the execution freezes up. Since the event structure is not being in execution so far, I'm expecting the button event should be simply ignored. Is it a normal behave of labview? Are there some options in the event structure setup should I check? thnx

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 RotarySw.ctl MainGUI.vi pannelloCanali.vi

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......

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