05-24-2010 02:15 PM
I would like to create a VI similar to the Build Array where I can have unlimited number of inputs, or make inputs increase in discrete numbers. I was told by the NI technical support that I should look into polymorphic VIs and VI scripting. I am pretty sure that polymorphic VIs is not what I am looking for. Scripting seemed a little too complex. I was wondering if someone could tell me a bit more before I spend hours with VI scripting and arrive at nothing.
I came across this post with a similar question http://forums.ni.com/ni/board/message?board.id=170&message.id=298298&query.id=3627080#M298298 that is over 15 months old. Has anything changed since then?
Is it even possible to create VIs that can be dragged to be long and have unlimited number of inputs? Or should I just go about another way to implement what I want.
Warm regards,
Bharath Bhushan Lohray,
Texas Tech University.
05-24-2010 02:24 PM
I don't think anything has changed since that thread was posted.
What kind of inputs are you looking to add? Is there any reason you can't do it by way of arrays?
05-24-2010 02:27 PM
Express VIs yes.
As posted in that thrad you will need th toolkit unless you already have it as part of the suite.
i read thru the instructions and you invoke a function that stiches it together and implements the expansion based on your selections.
I think there is probably a limit in the sense that you can only expand down as many inputs as you have coded. So if you code it to acept 12 and you need 13,...
Ben
05-24-2010 02:30 PM
The above was to pay a long over due request from Bill.
Ben
05-24-2010 02:32 PM - edited 05-24-2010 02:34 PM
Could you create an Express VI to do what you want?
( Beat to the punch again 😞 )
05-24-2010 02:43 PM - edited 05-24-2010 02:45 PM
05-24-2010 03:06 PM - edited 05-24-2010 03:07 PM
Lord Loh. wrote:I am trying to add an opCode and three operands (UINT16 enumerated data Types) and send it to the DSP as instructions on what to do with data that it is receiving from the ADC.
A 2D array is the way to go. Column 0 for the opcode, columns 1,2,3 for the operands. One row for each opcode. Number of rows only limited by size of memory.
Or you could get elegant and use an array of clusters. The cluster would have 4 elements, one opcode and 3 operands. Using clusters woud allow better labeling of your elements. An array of clusters again would only be limited in size by size of memory.
05-24-2010 03:19 PM
05-24-2010 03:32 PM
16 bits to contain the opcode and all operands? Is it 4 bits per field? You would have to shift the opcode by 4 bits to the left and add oerand 1 to it, then shift the result by 4 bits and add operand 2, then shift the results by 4 bits and add operand 3. (make sure none of your operands is greater than 15) Now you have a 16-bit code. In this case, use a 1D array of U16. Do your shifts and adds, then stick the result into the array. You could write a subvi to do the shift and add stuff, and another subvi to reverse the process to recover the opcode and operands.
05-24-2010 03:43 PM
That is what I was planing to do. I am yet to decide what kind of opcodes and operands I want. I have the freedom to allot the bits to the opcodes and operands as I have to programme the DSP to interpret those opcodes. I have about 16 operation in mind at the moment. So I may just allot 5 bits for opcode to expand. The operands shall be input and output buffers of ADCs and DACs or some intermediate storage buffers.
Since everything is fixed, I can have enumerated data typed for all of this and as long as the users of the toolbox uses these enumerated datatypes, they will not mess up the instructions sent to the DSP.