03-06-2017 10:58 AM
HI
I have to use the 1D array as LabJack specified. The 2D data is meaningless, so I have included the 1D Data the top byte is not used then the MSB is 2nd and the LSB is last the last 4bits in the LSB are not used.
Thanks
David
03-06-2017 11:02 AM
altenbach Why are you so rude I am trying to answer 2 different people you are picking up the wrong answers please do not respond if this is causing you so much anguish
03-06-2017 11:31 AM - edited 03-06-2017 11:33 AM
Hi David,
nobody is rude here. You just don't answer our questions!
Right now you just attached an image of a FP array control showing 4 values. That's nice, but doesn't help much!
What is the expected result for those values?
Why do you refuse to attach your VI (or any VI at all)?
I am trying to answer 2 different people you are picking up the wrong answers
That's why I tend to have the name of the person I'm answering in the first line of my message. You should do the same when you answer to different people in your thread!
03-06-2017 11:31 AM
I wasn't rude but we cannot help unless you give sufficient information. So stop posting useless pictures and attach real code as requested. Thanks.
03-06-2017 12:06 PM
On the left side of David's code snippet I see a call to LJM_eNames2D() from LabJack's LJM Library. This tells me that David is using a LabJack T7 and likely started with our simple example "SPI.vi".
The function eNames is a very general function that allows you to write and read multiple different arrays to/from multiple different registers on the T7, and thus it is handy for SPI where you can do all actions in a single call and single low-level packet:
1. Set number of bytes to transfer.
2. Pass array of write bytes.
3. Do the communication.
4. Retrieve array of read bytes.
The eNames function passes arrays of doubles as that allows all our different data types to work. In this case (SPI) each element is a byte so a likely first step would be to cast the array as U8. David does this after indexing the 3 separate elements, which also works.
Next he does his math to convert the 3 bytes of SPI data to a meaningful value ... presumably based on the specs of the SPI device. At this point he has one new value from his sensor.
He mentioned "125 Hz", so am guessing all the code shown in his picture is in a loop executing every 8 ms? That I suspect is where his question really begins. He has a loop iterating every 8 ms that is giving him a new I32 value, and he wants to add in some sort of FFT view? Perhaps show a new FFT once per second? Does that all sound right David?
03-07-2017 02:14 AM
HI
Thank you so much that is exactly right as you say I am using a T7 Pro and have lifted the code from the SPI.vi, I am struggling a little bit as this is only my second day using Labview I am not trying to hide anything I dont know how to put the vi on the site I only know how to screen grab.
I know my conversion of the I32 is all over the place but as I said I have only just started so any help with this and how to pass this data to an array and then to an FFT would be greatly appreciated.
Many Thanks
David
03-07-2017 04:53 AM
Hi GerdW
I have found where the vi has been stored and have uploaded it
Thanks
David
03-07-2017 10:32 AM - edited 03-07-2017 10:32 AM
For reference, the subVIs can apparently be found here.
As a first step, I would eliminate the coercion dots in the array building. The subVI apparently expects DBL. I don't have that much confidence in these drivers, some seem a bit amateurish (e.g. why are some of the array input terminals of "flatten2Dvalues.vi" inside the FOR loop????).
In any case, here's one possibility to (arguably?) simplify the conversion, but there are many other ways to do this. Please test. Good luck!
Now please explain what you want from the FFT.
03-07-2017 11:14 AM
I'll have to ask around about that github link, but the official source of the LabVIEW LJM wrapper is here:
https://labjack.com/support/software/examples/ljm/labview
As to why the array terminals were in the for loop in the helper utility "Flatten2DValues.vi", the most likely reason is no particular reason at all, but it could be someone actually put thought into it and decided a beginner would be less confused than having a non-indexing array tunnel. Since the time bottleneck is in the USB/Ethernet/WiFi communication with our hardware, we don't put much concern into LabVIEW code performance but rather prioritize minimal or simple code that works back to LV5. Actually, about a year ago we changed our official support minimum to LV6 so now use a few newer features such as expandable array indexers. I do think your comment here is good and we will change that VI and look for others with similar quick improvements. If you have other suggestions or feedback please do let us know at support@labjack.com.
03-07-2017 11:37 AM
@LabJackSupport wrote:
I'll have to ask around about that github link, but the official source of the LabVIEW LJM wrapper is here:
Thanks. I found the github link from a google search if the name of the missing subVI.
@LabJackSupport wrote:
As to why the array terminals were in the for loop in the helper utility "Flatten2DValues.vi", the most likely reason is no particular reason at all, ...
That particular subVI is a bit tricky because of the "soft autoindexing" of the inputs where default elements are returned if we run out of elements (thus disallowing autoindexing inputs, which would stop the loop short).
Code can always be improved and as long as it works correctly, it should be fine. (See also :D)