Mellroth
-
Posts
602 -
Joined
-
Last visited
-
Days Won
16
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Mellroth
-
-
Thanks a lot,
You're welcome
/J
-
...But I don't really understand how the timed loop works, so please take a look at the VI and tell me how to config it.
Hi,
Some comments about this GUI:
1. Using a timed loop with period set to 1ms, containing event structures with timeout set to 10ms, makes no sense. In this case the Event structures will probably time out in most cases, so the actual loop period will be above 20ms.
2. You are using local variables to create your log-data, and this could lead to race conditions, i.e. your log data can contain values before OR after the actual value update (and you really don't know which). Try to avoid local variables and go with the flow...
3. The X- and Y-scale properties are written in every iteration, even if no change has been made.
Suggestions:
1. Put the logging and all User inputs (except maybe the STOP) in a separate loop and send data between the loops using queues.
2. Avoid local variables if you can, you might not get what you expect due to race conditions.
3. Try to make the code more compact, as it is right now I have to scroll back and forth (using a resolution of 1400*1050).
4. You should also consider to fetch more than one sample at the time from the DAQmx (by setting the "number of samples per channel" to a positive value), this way you can get the loop rate down, but still acquire samples at the correect rate (100Hz). The current setup will return all samples gathered so far. If you set # of channels to 10, you can actually get rid of the timed loop and still have a loop rate at 10Hz.
I'm sorry I didn't answer you question regarding the setup of the timed loop, but I hope I have given you an alternative approach.
The reason is that a timed loop doesn't really add something in this case, because the timing can be controlled through the DAQmx calls. Timed loops are useful when you want to get good SW timing, but in this case you have the timing of the DAQ boards to work with.
/J
-
I've tried to use "Variant to Data" but I can't find a way to set the correct type.
How can I "split" it so I can display the values on my Interface?
Is there an easier way to do it? It may seem logical, but I'm new to Labview... so excuse me for "stupid" questions...
bigl00z3
Hi,
Do you really need to pass the dynamic data in the queue?
If not, then just feed the queue with the DBL-array you get from the "Convert From Dynamic Data" node. In the lower loop, set the array constant to an array of DBL (instead of U32) and use this in the "Variant To Data" node.
Good luck!
/J
-
The first attempt was to implement an wait-time between the start of the test and checking the error. This brought an slightly improvement, bu the error still comes up. The next step was to start the NI Spy to get information what is going on on the bus. Then I made a set of screenshots to compare the bus activities in the two cases (time-out and no time-out). But unfortunately I can't see the breaking point. Has anybody a hint for me?
I have seen something similar with a GPIB controlled Power supply.
In this particular case the problem was that the PS could not handle commands at a rate higher than 25Hz. The solution was to limit the instrument access to this rate, i.e. make a check that at least 40ms has passed since last call.
We also had problems with LabVIEW RT (7.1.1.) and VISA. When VISA write was performed asynchroneously, it caused the RT application to crash after a while.
I don't know whether this applies to you, but...
/J
-
First, I'm sorry if I offended you in anyway by my previous post. It was not my intention, and I appologize if you felt offended.
Well, sorry if didn't meet your expectations. Sorry, if this is not as simple as you expected too. I hoped that on this forum the majority of people would not consider it too complex.I think that a template should be simple to understand even if it performs a highly complex task under the hood.
So the tasks performed in your template are not too complex, but I felt that the usage could be simpler.
I didn't quite get this about "methods to add state(s), get next state etc." The next state is always in the respective shift register. You can check it from within your actions but in general it's only the Run State Machine action that is supposed to do that.The reason for my comments is that I made a very similar approach back in LV6i.
In this approach I encapsulated the queue primitives and added error handling/idle state/priority(putting on front or on back), within the encapsulation VIs. This way the user don't have to know if I'm using queues/LV2 globals/... to pass states, so I'm free to make changes/updates when new "better" primitives (e.g. user events) are released from NI. For the end user the API will always be the same, regardless of the actual implementation.
Would you prefer them running behind other objects?Nothing prevents you from adding additional shift registers for your data. The pattern itself uses one to store the next state.
I don't like to see wires get behind other BD objects, but as there are only 4-5 wires entering the loop this should be pretty easy to avoid. E.g. if the queue references that enters the loop also exist the loop then these wires can be used for the Destroy Queue actions instead.
Maybe it is just me, but I prefer to add shiftregisters for the error cluster even if the loop exists on the error.
Error handling: Well, yeah, I could have added generic error handling, but in many applications errors are handled (different actions run, different error states exist) differently depending on what that error is. Plus, this would have added more stuff to this pattern that is already perceived as too complex by some.I would recommend to catch specific errors inside your specific actions and throw a corresponding specific (or generic) error event which would cause the module to go to a specific (or generic) error state. This would allow you also to handle requests for error reset differently for different errors (again, if needed, of course).
My point was that if your template does not exit the state loop on error, you might end up in a free running infinite loop (e.g. if the action queue fails to initiate for some reason).
In my approach I passed the error in a shift register and the GetNextState triggered on error and put the state machine in a error state.
/J
-
...My worries is about the configurability of the channels when the executable has been build - if another computer has registered the DAQ-pad with a different name (e.g. "Dev2") I suppose I won't be able to run the executable?...
If you define channels in MAX, and then use these channel names in your application you should be safe.
If you have to exchange a device (or rename), you only have to update the channel config in MAX.
I haven't acually used the express VIs, but as it works for the DAQmx I suppose it will work for express VIs as well.
/J
-
Hi
I have tried this method though the NXT block is not responding.
Just ignore the web cam controls on the bottom.
Just some quick notes:
1. your program are using I32 constants instead of U8 (doesn't really matter)
2. you could implement this with an event structure, to get more direct user response
3. I personally prefer to open/close VISA sessions explicitly
Do you get any errors? If so what errors do you get?
/J
-
What would the message format be?
It would be easier if you could show some code.
I also think I slipped when I said
So if you have a U8-array with the values [00, 09, 01, 02, 01], feed this array into the "Byte Array To String" function (or a typecast node), and the output will be the string to send. Or enter the values manually in a string control that is set to display strings as hex values, then just send this string.sorry for that.
/J
-
My first impression when I opened the block diagram of the program was that it wasn't as simple as I was expecting. I see there is a lot going on, and I can follow most of it, however I guess I'm just missing something because I don't get the advantage to using this over a single queued event driven state machine. Another thing thats clouding my understanding of the code I think is the confusing routes of most of the wiring.
I have to agree, I was expecting some kind of simple state machine toolkit, e.g. with methods to add state(s), get next state etc.
Sorry, I really don't see where the wiring is confusing, but I will appreciate any corrections that would make it clearer.Regarding wiring, wires are going up/down, inside/outside of loops and this becomes pretty hard to follow.
I'm also missing shift registers and error handling within the loops.
As I said above, I think your template would benefit from encapsulation in logical methods.
It also seems like a good idea to bundle all your references as they seem to be more or less needed everywhere.
/J
-
...Send Integer value of 1 : (0x00,0x09,1,1,2-10)
When Converted its
3078 3030 2C30 7830 392C 312C 322C 31
Perhaps I should remove the commas and send this hex >3078 3030 2030 7830 3920 3120 3120 32
I don't think you should convert the ASCII values to hex, but rather the values contained in the string.
Your output "3078 3030 2C30 7830 392C 312C 322C 31" is the hex representation of the ASCII sequence "0x00,0x09,1,2,1".
If you are going to send this sequence as hex, I would guess that your program expects the following hex representation
"0009010201".
So if you have a U8-array with the values [00, 09, 01, 02, 01], feed this array into the "Byte Array To String" function (or a typecast node), and the output will be the string to send. Or enter the values manually in a string control that is set to display strings as hex values, then just send this string.
/J
-
...
alt1 - is using an array... wouldn't it nessesary to empety this now and then?
alt2 - Better? safer (in terms of memory handling)?
...
Hi,
Does alt1 write all data sampled during 1h? If so then I would recommend that you use alt2, as you don't want to loose data if the computer crashes after 45min.
If you are running late in the alt2 case, try to separate file writing into another loop, sending data through a queue (or an RT-FIFO).
You could also configure the DAQmx to return 1000 samples in one shot, and then write 1000 samples at the time to the file.
The loop time would then be 1s instead of 1ms, and sampling is performed by HW (i.e. with more precise timing).
/J
-
Found another minor improvement.
When you are using up/down arrows to increment/decrement values in a control, the increment value does not move from one power of 10 to another, e.g. increment from 1 to 10 and when 10 was reached (..7,8,9,10,20,30,...). In LV8.20 this is now ...7,8,9,10,11,12,13....
The change is actually that the cursor position is kept at the same position from right instead of left.
/J
-
...so,what can i do to overcome that problem?
As Pete said, you wont get a definite answer unless you give us more information.
Upload a screen shot, showing both the write and the read TAB of MAX.
Don't bother with LabVIEW until you have the *IDN? command working from MAX.
I do think that this is a setup mismatch, as I would expect more than 6 byte in return for the *IDN? command.
/J
PS. its LabVIEW not labview (for you crelf
) -
No external links to large images please.
There is also no need to include the complete post when you are replying.
/J
-
As crelf is saying it is almost impossible to give you any help from the information you have given.
You could, however, try to use some of the examples that ship with LabVIEW to perform simple serial communication.
If MAX is able to read back the *IDN? response, so should LabVIEW.
/J
-
... and so on for up to 7 "priority" columns. Why 7? It would get more and more clumsy for more priorities (see middle diagram below), and I couldn't figure out how to make it inherently flexible.
Hi,
maybe this could be a way to sort on an arbitrary number of columns.
Flow Formula - Dwyer Averaging Pitot.vi
Attachment is in LV8.20
Download File:post-5958-1163081605.vi
/J
-
Maybe you can use a .vit (VI template) and open a new VI based on the VIT and use this as the reentrant VI
I don't think this will work in a run-time environment, only in development.
/J
-
The easiest thing I can think of is to unbundle the cluster elements, then re-bundle them with a Bundle function, with no datatype specified on the middle terminal. This should remove label names from the cluster data, leaving you with only the data types.
-D
If you use the bundle primitive, I think it uses the names of the connecting wires as the cluster element names. Or does this only apply to when inputs are from controls/constants?
I don't have LabVIEW available at the moment, so I'll have to check this tomorrow...
/J
-
:arrow: Disclaimer: I have no US political affiliation.
Funny clip. We should invite Bush & Bush to take part in the neverending by-reference vs by-value discussion.
/J
-
...I include the option to process the training set in a random order each time it is used. To do this random processing, I implemented the random permutation in LabVIEW.
Have you considered using random numbers with a seed specified, e.g. by using Uniform White Noise.vi. This way you could run exactly the same sequence of "random" tests with a new model.
/J
-
I have one while loop that is only responsible for raw acquisition. It acquired raw data strings (such as: On, pressure, 23.3, 34, 3.4...) Each of these raw strings pass through a comma check to ensure they are in the correct format. If the string passes the check, it is passed out of this while loop through a notifier. I have a count that keeps track of every time a strings passes the check, and it adds one to the count each time this happens. Therefore, if a string doesn't pass, the count won't add one, or if the controller stops outputting data, the count will not increase.
If I understand your problem correctly, the loop that receives data from RS232 continues to count, but the reeceiver of the notification stops adding data to the arrays? Could be a problem related to your notifier, have alook at the thread
http://forums.lavag.org/index.php?showtopic=4220
Jimi found out that notifiers can stop working (and eventually cause a hang).
I don't know whether this applies to your program but it is worth checking out.
You should also consider to replace your notifier with a queue, since notifiers are by nature lossy while queues are not.
/J
-
I'm missing an outer loop that inserts another beer into the system
/J
-
Yep. MATLAB does generate numbers between 1 and N because MATLAB indexes arrays starting with 1 instead of 0. I can add a recommended boolean input to switch the indexing to 1...N.
Sounds good, and it was a very nice implementation.
If you are going to do a change, it is enough to use one "index array" node plus one "replace array subset" node.
Then you could add a "convert to I32" before feeding the random number to the array functions, this way you will only have one conversion from DBL to I32. Just to make the code even cleaner (IMHO).
/J
-
Good stuff - thanks for that!
You don't need to convince me of that
Due to it's amazing whiskies (rich peats, clear waters and salty air - what a combination!), it's well on the top of my list!You are welcome.
If you go to Islay, I would suggest at least taking a short diversion to the opposite side of the penisula where you catch the ferry to go Islay and at least get a good view of the Isle of Arran, its a breathtaking view!I would suggest to take the ferry to Port Ellen but depart from Port Askaig, since the ferry can take you directly to Oban. Next stop, next whisky
I had to look up the name of the place where we stayed, and my memory served me well, the name was Kintra
Brings back a lot of good memories: 3 days, 7 destilleries, ~20km by bike.
I tried to upload a picture with a view from our stay, but failed (don't know why). Anyway, sitting in that small pub, drinking whisky and beer eating garlic toasts, Mmmm :thumbup: :beer:
/J
GPIB Error 6 with ITC55100
in Hardware
Posted
I actually don't remember, but I know we upgraded to the latest versions (as of September -05 Februari-06) of DAQmx, VISA etc...
We were able to reproduce the crash with a very simple program, and this was sent to NI in a bug report.
I'll see tomorrow, if I still have the bug reference/test program lying around.
Since there was an easy workaround we have moved on, and the system is running as it should.
Edit:
I found my bug report, but not the test program.
/J