I use a MacBook as my personal computer. Because of FRC, I dual-boot WinXP along with my Mac OS 10.6.
On the Windows side I have LV 8.6 (FRC) and LV 2009 (FTC).
On the Mac side I have LV 8.5 (FRC 2008) and LV 2009 (FTC).
I know there’s no reasonable way for me to deploy code to an RT target from the Mac side, but I do use it for some development, or if someone asks about how a VI works. I’ve copied the Robotics Library (and its menus) over, so I can place down functions, or look at old code I’ve made.
Of course, many things I open up, LabVIEW searches for the frameworks they rely on. (They were DLLs on Windows, but on Mac they’re frameworks, and so they don’t exist; copying them over won’t do any good.)
Is there a way to make dummy frameworks (like nivision.framework and NiRioSrv.framework) so that I don’t have to ignore those items when LabVIEW is searching for them?
This may seem crazy to many of you, but I enjoy developing on Mac, mainly because of the better window control, mouse control, and stability.
Hi. I have only used the Mac OS on a Virtual Machine, and not a lot with LabVIEW. Most cross platform implementations use the disable structure with the project “conditional disable symbols.” Typically they would be placed around the DLLs or other platform specific code. Although, I suspect making wrappers for every vision VI that you use is probably going to be time consuming. You could try using the disable statement around the whole vision section and other problematic areas in your robot code.
I considered using VI Scripting to put disable structures around the CINs. However, I’m not familiar with how to place a structure around elements (I believe you have to place it down, move everything inside, and then fix broken wires). I also was uncertain of how to configure the conditional disable structure with scripting.
If there isn’t a way to make dummy frameworks, I can just keep pressing “ignore” when LabVIEW searches for them.
I have not played with scripting enough to give an example of that. I would put it around the code in your upper level VIs to keep life simple. If you really want to, you could just copy the whole library to your MAC side and go through all of the VIs to remove the offending code. (You could also use scripting for that) I don’t recommend this though, as it makes it very difficult to upgrade/move. Any VIs connectors or references change between versions, it would cause broken code until everything is relinked. Modifying libraries are generally not recommended.
Hi, my name is Greg, and I too use a Mac. I’ve been using since 1986, and I use numerous times a day. I hardly go a day without using.
If I’m loading FRC stuff, I typically just hit ignore a few times. I’ve never bothered building frameworks with the right entry points.
The other thing I do is to run parallels with Win7, LV, and other SW installed there. To keep the battery usage down, I typically have the VM paused. It only takes about five seconds to resume. Because the clipboard works transparently between the VM images, and one of the disks (Z) is mounted on Win7, I can pretty easily do everything I want. I still get stymied by networking sometimes. I end up going through the various Bridged and Host-Only settings until I find something that works.
Once upon a time, NI had a version of RT host for the mac, but there simply weren’t enough purchases to justify the testing effort of the various protocols and configuration tools.
If you have any questions about the scripting, or any success, let me know. A slightly different approach would be to copy the VIs over to the Mac, and don’t bother with the disable node, but instead, use scripting to delete the CLF nodes and remove bad wires. This will leave many of the VIs stubbed and returning defaults, similar to what you’d get if you disable the CLF.
Thanks, that answered my question. Building dummy frameworks isn’t worth it.
I might delve into scripting sometime again (perhaps this summer?). It would be really nifty to find broken pieces of code (and drill down to the lowest level it can), and disable them.
However, your solution of just deleting the CLF nodes and FPGA invoke methods would probably be easier.