Labview 6.02 unexpectedly exits in Mac OSX

[Jim Downward]

I have been trying to use Labview 6.02 running as a Classic application under Mac OSX 10.2. My goal was to use the OSX 10.2 system for development of DAQCard applications which would be run on Powerbooks. For small VIs (so far) Labview seems to run more or less properly. However, for larger VIs, LabView will unexpectedly exit without any error message (even when it is idle) or it will exit when it tries to open the VI in a VI library. I have tried a variety of different Classic environment extension sets, but no change I have made has reduced Labview's tendency to suddenly exit. I have found no error messages in any logs which shed any light on the error condition which is causing Labview to exit.

Has anyone any idea as t
o what is going on or if this instability can be reduced?

Of course, what I really want is to be able to run LabView under OSX and have it support DAQ acquisition on the portable Macintosh data acquisition systems we develop.

[Jeremy Braden]

LabVIEW 6.02 was not developed to run under OSX. What happens when you launch in OS9?

As a crazy longshot, have you tried having LabVIEW use more memory?

[Jim Downward]

Thanks, but I have set LabView 6.02 at 35,000KB which is substantially larger than the recommended 20,000KB. Using the Classic Memory/Versions pane, I have observed memory usage and with the VI loaded, LabView is using less than 1/3 of its available memory. I don't think lack of memory is a problem.

[RL]

LV will not recognize the hardware in compatibility mode. To use classic LV you have to boot up in OS 9 derivatives. If you have a new computer you cannot boot up in OS 9.

Running Labview 7 in OS X is an exercise in using crippled software. The NI plan is to double the software costs for Macintosh users by forcing them to buy the Real-Time module. The DAQ boards are not supported under OS X unless they have an Intel processor.

The words "NI shaft" is not out of place in this context especially for those who paid for the Software Suscription or the upgrade to Labview 7. I would like to believe that NI will rectify this oversite but my optimism is waning.

RL

[Jim Downward]

Thank you for your input, but I do understand that LabView will not recognize any hardware when running in Classic mode. It is not my intent to run any VI's. I just need to edit them to make minor changes and then to rebuild applications using them which I will subsequently test on machines running OS9. The issue is why, when I have a VI open to edit, will LabView suddenly Exit without me doing anything, no mouse clicks, no menus, no anything. I am in another application and BAM, LabView exits without any error messages.

I agree that NI's OSX "solution" is not a solution, particularly if one must develop and maintain field portable data acquisition and control system for measurement instruments. My company needs to be able to acquire data cost e
ffectivly using DAQCard, USB, or FireWire devices. None of NI's current offerings for OSX come anywhere close to meeting our needs.

[RL]

Jim,

More to the point of your question. I have LV 6.1 open in compatibility mode. There has not been a crash when editing, opening/closing other programs, or running the .vi. To go any further I may need an example of what you are doing. Alternatively you may want to update to 6.1 and get the latest OS 9.2.2. A check of Classic preferences in OS X tells me that the version of Classic Support is 2.1.1, that the Classic Enabler is 9.3.4, and that the Classic Environment is Classic version 1.7.7, build 141.25, Mar 26 2003, 11:38:12

Getting Channel & Solution Wizards to work is another matter.

[Jim Downward]

I am using 9.2.2 in compatibility mode under OSX 10.2.6. I did not know 6.1 was an upgrade option at this point. I have noticed that some VIs don't seem to crash but that my main VI, which is a very, very complicated one (written by someone else) which calls dozens (if not hundreds) of other VIs, will crash if left open. It does not crash if I boot into OS9.2.2. If the crash was posting any message to a log file or screen, I would be far better off. But LabView just exits as if it had been sent a Quit Event.

[Greg_McKaskle2]

> I am using 9.2.2 in compatibility mode under OSX 10.2.6. I did not
> know 6.1 was an upgrade option at this point. I have noticed that
> some VIs don't seem to crash but that my main VI, which is a very,
> very complicated one (written by someone else) which calls dozens (if
> not hundreds) of other VIs, will crash if left open. It does not
> crash if I boot into OS9.2.2. If the crash was posting any message to
> a log file or screen, I would be far better off. But LabView just
> exits as if it had been sent a Quit Event.

I'm coming in a bit late here, but that is largely because I don't have
a solution, just a confirmation that I've seen this behavior too. I
recall it being worse with early versions of the classi
c OS and getting
better over time.

This is actually a very difficult problem to look into since the
development tool used to write LV for OS9 in will not debug when run
under classic, and the bug doesn't happen in the true OS9 environment.
So, our time was spent working on OSX version of LV instead. Which in
spite your comments about the lack of driver support is a nice product
IMO, and our belief is that the crash is either an OS issue or is highly
affected by the OS.

Greg McKaskle

[RL]

Greg,
You obviously know things we do not. At this time Labview on the Macintosh is something only a mother could love.

LV 7 Classic will not find DAQ cards in 9.2 Classic mode. This means that it will not work on newer computers. It also means that we have to reboot to use OS X applications, then reboot "true OS 9.2" to return to LabView (does NI see a problem here?).

The policy behind LV 7 for OS X did not result in a "nice product". NI is telling us to "go away" without the having the courage to say so.

This wasteful strategy means; users have to scrap existing DAQ boards, run two operating systems, buy Real Time module, and buy a card carrier if they use more than one DAQ board. Entry level DAQ will be th
ree times as costly on the Macintosh as on the PC.

How does this "nice product" strategy allow me to use my DSP board and the three other DAQ boards in the future? HiQ is scrap, what's next? All this has happened a year after I received from an NI executive:
"First, we are not dropping support for the Macintosh platform. We are currently developing the next version of LabVIEW for MAC OS X."

You may have all the reasons to be proud of your code but the group was guided by ill conceived policy. What is NI going to do rectify this situation?

RL

[Jim Downward]

Greg
This is not personal, but "Nice Product?" Current model PowerBooks, even though they still have one DAQ slot, can NOT boot into OS9. We had a Macintosh, DAQCard-based portable system we sold to control biosensor instruments we manufacture and sell. We can no longer sell these instruments because we can not run the LabView applications we developed (at very considerable cost), on current Macintosh computers which only can boot OSX. We are now having to rewrite everything to run on PC systems.

The situation is incredible. How can NI possibly imagine that current OSX support addresses the needs of customers who have been using DAQ-based solutions for a decade or more?

How can LabView support drivers for
Linux but not OSX? 13 years ago I used to develop OS code for a variety of DEC systems (RSX11M & VMS). At that time I remember the general wisdom was that porting drivers between unix systems was generally straightforward.

Perhaps NI should consider supporting Mac systems under OSX by providing a low-cost FireWire box which had an internal buss into which your DAQ cards and DAQcards would fit. The low-level OSX FireWire driver already exists, so NI would only have to develop the a serial to PCI board and a VI to serialize DAQ communication from LabView to the FireWire driver. Unfortunately, your current FireWire DAQpad offering is neither supported under OSX, cost-effective compared with other PC DAQ solutions, nor expandable.

Jim Downward