jacobson

Still working for NI. Posting to LAVA is something I do on my free time and, if possible, I would like to keep work stuff and personal stuff separate. If it's a pain to do though don't worry about it

You can do this with NI FPGA hardware as well, once you compile the VI just click run.

They posted a product page for a Pocket-RIO in their own thread. It looks like the same company that developed the Hand-RIO. lavag.org/topic/19867-labview-can-support-any-xilinx-fpga/#comment-120359

Kind of silly question, but is there a way to remove the NI tag from under my username? If I just link my account to a non-NI email will it be automatically removed?

The only way I could find to get the module type would be to use the Get Tag method of the project item and use the tag crio.Type. You can get a lot of other information that way, just look at the project XML to see what tag you want to use. The following is purely speculation on my part but I would not expect there to be a simple way to interact with the modules through scripting because the cRIO project items are populated by a project provider from the RIO driver so it doesn't get any more specific than project item in the VI server

Can you attach a simple project you are working with that has modules that doesn't show up using the OwnedItems[] property? Once I got the reference to the project I was able to use the Targets property to get a reference to the cRIO item and then dig down using the OwnedItems[] property. The RT target owns the chassis which can own both modules and the FPGA target. The FPGA target can also have modules as the owned items so you may have to dig down to find what you are looking for but it should be there. For each level of owned items I used the DisplayName property to see what was there and was able to find modules under the chassis and FPGA. Alternatively, if you are looking for a more run time based approach there is the new SMI toolkit. https://decibel.ni.com/content/docs/DOC-48647

If I'm feeling ambitious I might try writing a kludge of my own. The error is caused by the input to the update state ability being different based on whether the VI you are dropping the macro into is saved or not if someone wants to try fixing it for real.

If you have SSP you can try ni.com/self-paced-training as well

I thought I double checked that but I'll make sure tomorrow, thanks for the suggestion. Edit: It was there, same behavior when it wasn't in my ini so good to know I don't need that token.

To follow up on this thread, the error above only seems to appear in LabVIEW 2016 if the .vim is dragged onto a saved block diagram from windows explorer and has been reproducible on multiple computers. You are still able to use VI macros either by scripting them onto the block diagram or dropping one from the palette (add it to user.lib as JeffK originally suggested). This behavior is not the same as it was in LabVIEW 2015 SP1 or earlier which was confusing for me.

Clearing the cache didn't seem to do it. After looking into this more, the error is being thrown by the VIM xnode but I'm still not sure under what conditions it throws that error. I also think the strange context help message is just what shows up if the context help of the VIM you drop is blank.

I am getting this strange error whenever I try to drop a .vim into a VI that is saved. If the VI is not saved, everything seems to work but as soon as I save it and try to drop in a .vim, I receive this edit time error. This happens to any .vim file, even blank ones that I have just created. If I double click on the error then it will highlight a specific object that I can delete but the object is otherwise invisible and unclickable. This started happening right after I tried to add a VIM through scripting. I can actually still add a VIM through scripting but it has some pretty interesting context help. So I guess the question of the post is what the heck did I do and how can I get LabVIEW to start behaving again.

Can you give an example of what you are trying to do? I'm having a real hard time understanding the problem. There is an Add Array Elements function which will sum the 1D array but I have no idea where this 2D array is coming from.

So in my original plugin I did not modify the VI in the build menu part of the plugin and it still crashes. For my own interests is there some decent documentation about the undo stack and how that works? Edit: forgot to mention it never seemed to crash when actually changing the structure, mostly just undoing as far as I remember. I couldn't get consistent steps to cause this though so I'm not really sure.

Didn't know about the case changing. I did a quick search through properties after finding that the style still reported that the TES was a DDS (even though there is a style for TES) but didn't find anything I thought would be too useful. I also ran into the same problems when trying to start/end a transaction. Crash dumps do report having "Replace with Type Enable Structure" in the undo stack so something is starting/ending it. I'm not sure if messing with this would even help but the crash dumps report a whole bunch of fatal insanities and problems with undo.cpp which is why I was looking into that. It was the first time I've ever seen "Exception: Unknown (0x00000000)" though which I thought was interesting.

Since there doesn't seem to be a good way to get this structure from the palette I created a right-click plugin that will replace a Diagram Disable Structure with the new Type Enable Structure. If you right-click a DDS, you will now see the option to "Replace with Type Enable Structure" underneath the "Replace with Conditional Disable Structure". As a warning, LabVIEW doesn't seem to like what I did and will crash sometimes when undoing or when replacing a TES with a TES. If you can easily see what I did wrong please let me know. Also, if you can find a way to figure out when you have right-clicked a TES and not a DDS it would help solve the second problem. Replace with TES.llb

Turns out this one is on the known issues list (390021 in case the link doesn't take you to it directly) http://www.ni.com/product-documentation/52698/en/#390021_by_Category I would have expected that an inlined VI has the same priority as it's caller but I guess not.

I would be interested in what happened with that support interaction if you are okay with PMing me the service request number. Aside from that I would agree with Ned, but I wasn't able to figure out a way to test this where everything wasn't completely optimized out or where the differences in execution timing couldn't just be explained by the changes that I had to make for LabVIEW to not optimize it out.

I'm excited to be going this year, can't wait.

Got it working, just needed to ask someone who knew what they were looking at. I needed to make a change to the "Create AXI4-Lite Resources.vi" which is next to the instruction framework interface on the FPGA. The Address Space Size is 0x800 by default so it just needs to be made larger. I compiled successfully at 0x1600 but I was told the correct size is 0x1200. Matt J

I'm at a loss for what could be happening so I'm hoping somebody else has done something similar. I am using LabVIEW 2015 SP1 with the FlexRIO 15.5 drivers with the 7935R and receive an internal software error when trying to compile the example project "NI793xR - MGT Aurora CLIP.lvproj" when generating intermediate files. The Error I'm getting is copied below. Error -250514 occurred at Possible reason(s): An AXI4-Lite address map element cannot fit in the specified address collection. Make sure that each address map elements' offset plus size does not exceed the address collection's total size. My goal is to replace the DRAM FIFO that is currently being used to write to Port 0 with a Count Up, Count Down, or PRBS signal. I was receiving the same compilation error after trying to make these changes. I tried to be very careful with what I replaced and was pretty confident that I hadn't touched any of the AXI4 functions. I tried compiling the example project because I was going to start over and make sure I had a good starting point. The example does run but that's using the bitfile that's already compiled. I've tried compiling using the cloud as well as a company compile server. I'm also installing software so I can try this on another computer. I don't think I need the tools locally for this but I might try installing those to double check. Pretty much out of ideas and wasn't able to find much online so any help would be appreciated. Matt J Edit: Same compilation error on second computer with local tools, both Windows 7.

Dang, couldn't find this structure in the last LabVIEW build and got 0 hits when trying to find more information about it internally. The thought had crossed my mind that JeffK just made this all up for his own entertainment and while I would be a bit sad, I would definitely respect that. I guess I'll have to wait patiently with everyone else until release.

From what I remember about VI macros, the output terminals are kind of unique (I think) in that they will coerce to whatever you wire them into. If this is true, what would happen if you wire the output of a VI macro into one of these new structures? Theoretically if you had a chain of these you would start in the beginning and find out the enabled structure that will be used, this would set the output type which would then determine the input type of the next enable structure and so on. Would the compiler be able to figure this out or would it probably fail here? I'll be the first to say I have no idea when this would be done, just interested to see what our new toys do.

That's strange, I was able to add a folder to a class in the same method you are. I attached the project I used which basically shows the same thing. Check the name property of LV Reference 2 before you try to add a folder to it. If the Name is the class you are trying to write to, I bet you aren't saving the project after adding the folders which is why you don't get an error (because the folders are created) but why they don't show up (the project is never saved). Script Class Folder.zip

Thanks for the input. I kind of expected that we wouldn't be able to change that behavior because some of the LabVIEW Xnodes do this but I figured I would ask since my Xnode is much simpler than a lot of the ones used in the development environment. Looking forward to the presentation next week hooovahh.