Mellroth

Well done :thumbup: I'm sorry I haven't replyed to your last posts, but my knowledge regarding the Fantom SDK is NIL By the looks of your program, I think you should add error handling in the loops, maybe break loop execution upon an error? There is also no visible delay in the upper loop, and this together with the lack of error handling can get you into trouble. /J

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

You're welcome /J

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

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

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

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

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

It would be easier if you could show some code. I also think I slipped when I said sorry for that. /J

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

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

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

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 )

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

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

I don't think this will work in a run-time environment, only in development. /J

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

Funny clip. We should invite Bush & Bush to take part in the neverending by-reference vs by-value discussion. /J

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

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

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