Sadly, it looks like you have to be a student though.

Thanks,

-John

===========

I found version 8.0 bloated and slow, especially compared to version
7.1.  It also slowed my computer to a crawl, even when it wasn't
running.  Version 8.0 was even worse than 7.0.  Version 8.2 was a little
bit better.  Version 8.6 was usable, however NI dropped support for
older systems, which is what I was supporting at the time.  The LabVIEW
Project (which was added in 8.6, I think) made life easier.  LabVIEW
2009 is pretty good.  I haven't had a chance to really test LV2010.  I'm
working with real-time systems and LV2010 isn't recognizing them yet.

For quick and easy use of GPIB, LabVIEW can't be beat.  It also gives
you easy graphing and saving of data.

In a separate email to the list you said that you wanted to play with
PCMCIA GPIB on an older Thinkpad.  I recommend you use version 7.1  It
will do everything you need without bogging down your computer.  For
hobby use, 8.6 doesn't really get you anything and may be too much for
your laptop.  I used to run 7.1 on a 1.4 GHz Pentium M laptop, talking
to three Keithley meters and a switch chassis over GPIB without any
performance issues.  I also ran the same test systems with 600 MHz
Celeron processors and 256 MB of memory on Win98, Win2000, and NT 3.5
systems using 7.1.  On those slow, memory-short systems, screen updates
were a little slow but I never missed any data.

Note that none of NI's PCMCIA products work with Vista or Win 7.

Brent

On 8/17/2010 8:15 PM, J. Forster wrote:

Hi

Continuing education at the local community collage is your friend. Do it online and you don't even spend gas money.

Bob

On Aug 17, 2010, at 10:26 PM, "J. Forster" jfor@quik.com wrote:

Thank you very much.

I just bought a NI PCMCIA card and seperately the cable on eBay for a
total of $115 to use in a T-20 or T-30 series Thinkpad. They are available
for about $100 w/ 500 MB + memory and a 20 GB+ HD.

Having an upper limit on the useful LabVIEW Rev numbers is very useful.
I'm basically playing and am not trying to build a high performance ATE
system.

Best,

-John

==============

Bob Camp wrote:

Not always.. e.g. Matlab says: "The product is solely for use in
connection with courses offered at degree-granting institutions, either
by students working toward a degree, or by continuing education
students." "They are not for personal, professional, or commercial use.

and they do "check ID"
Proof of student status is documentation that confirms that you are
currently a student enrolled in a degree-granting institution. To
successfully authenticate as a student, you must provide us with
acceptable proof of student status by uploading a digital copy of any
one of these documents:

I doubt that they'd call the school to see if you're taking a class that
actually could use matlab ("Aha, we see you're taking 17th century
English literature, how ARE you using Matlab in that?"  "Why, I'm using
it to do statistical analysis on the works allegedly written by
Shakespeare to determine the actual author.")

So, you'd be splitting hairs a bit... (not likely that the mathworks
police are coming after you)

Hi Didier,

No - the display reads "DAC V: 0.0000" on the iCruse LCD, all the other
data (including temperature) displays normally and correctly. So it is
only that part of the data which doesn't seem to be decoded and
displayed correctly. The really odd thing is that the DAC V value can be
seen in Tboltmon.exe, although I realise that that particular program
also sends data to the Tbolt, which the iCruse does not.

The reference to the RS232 resistors was in the context of the
discussions regarding whether the values in the iCruse are correct -
but of course if all the other data is being received correctly, there
doesn't seem to be any logical reason why the DAC data would be any
different.

Thanks for the reply, but I'm still puzzled!

David, G4IRQ

On 18/08/2010 12:33, Didier Juges wrote:

"there doesn't seem to be any logical reason why the DAC data would be any different."

That is the kind of thinking I do often, and usually end up kicking myself in the butt later for :)

It could be that the serial data is corrupted during the transmission of the DAC value because of a particular bit pattern. It is not like the design of the RS-232 converter is bullet-proof... I had a very similar problem here at work just a week ago for the exact same reason (cheap RS-485 to RS-232 converter messed up one particular type of message, but worked well for over a year prior to that)

I have nothing else to offer, nobody else has reported this problem, and as I pointed out earlier, the code is basically the same that is displaying the temperature.

Another possibility is that the chip's firmware may be corrupted, in which case it may need to be reflashed.

Other than that, I don't know.

When facing something apparently illogical, do not exclude possible causes simply because they are improbable... If the solution were where you expected it, it would be already fixed, and if there were no problem, we would not be having that conversation :) Look under all the stones, not just those that look to be about the right size.

Didier

Sent from my BlackBerry Wireless thingy while I do other things...

-----Original Message-----
From: David Bobbett d.bobbett@tiscali.co.uk
Sender: time-nuts-bounces@febo.com
Date: Wed, 18 Aug 2010 16:03:22
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Tbolt and iCruse readout problem - any ideas?

Hi Didier,

No - the display reads "DAC V: 0.0000" on the iCruse LCD, all the other
data (including temperature) displays normally and correctly. So it is
only that part of the data which doesn't seem to be decoded and
displayed correctly. The really odd thing is that the DAC V value can be
seen in Tboltmon.exe, although I realise that that particular program
also sends data to the Tbolt, which the iCruse does not.

The reference to the RS232 resistors was in the context of the
discussions regarding whether the values in the iCruse are correct -
but of course if all the other data is being received correctly, there
doesn't seem to be any logical reason why the DAC data would be any
different.

Thanks for the reply, but I'm still puzzled!

David, G4IRQ

On 18/08/2010 12:33, Didier Juges wrote:

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi David:

What power supply voltage are you using?
http://www.prc68.com/I/ThunderBolt.shtml#iCruze

Have Fun,

Brooke Clarke
http://www.PRC68.com

David Bobbett wrote: