An invitation for discussion.

I have been a member of the FlukeView Forms development team from it's beginning in 1997.
I can share some FAQ's and Tips.
I can listen to your questions and to how you use, or would like to use, FlukeView Forms [FVF] to accomplish your goal.
I can take what I learn into our planning process for future development.

Limitations:
I can not reply to all questions.
[Fluke support is available to answer urgent questions as needed.]

I will read the thread at least once a week.

I'll try posting an FAQ - perhaps based on the discussions, at least once a week.

I'm an engineer, I misspell words and go off on tangents.

This is FlukeView Forms - not FlukeView for the _______meter - different products, different teams.

I will not flame - and would ask you do the same.

I will not be promising new features - understand please, I can not.

Consider me another user posting after work.


With that in mind,
Ancient History
-as in FYI and it seemed a logical place to start-

Prior to FVF, much if not all of the Fluke software to work with Fluke meters was "companion software" - meant to provide access to the data in the meter or available from the meter. One 'exported' that data, or copied a bitmap to another application to document the test. The job was not done until that 'other' application captured the findings. FVF was developed to be 'application software' where the application was documentation.

We saw two primary use cases.
1) Where a user was completing a printed form by manually entering meter readings, FVF was to allow that form to be created as a template and data taken directly from the meter into the form.
2) Where the goal is to either find and document an intermittent in the equipment under test - or provide documentation that no intermittent was detected.

FVF was developed in parallel with the Fluke 89-IV such that together they could provide multiple customizable views of the data collected.
[and yes, export the data and bitmaps to other applications as needed]

FVF is a database application. This to allow keeping the “form templates” [forms] together with their readings so one could compare historical data.
A further evolution of FVF was to be developed to allow test point readings on a particular form to be viewed as a trend.

In the ten years since the FVF 1.0 release, I have heard from perhaps a handful of users filling in a custom form with test point data. Not surprisingly there has been little call to develop ‘historic view’ across saved forms.

There have been eleven releases of FVF to date. With each release, we review the new features we would like to add with the product planners, prioritized based on customer input as well as long term goals.

FVF 3.4 is about to enter final test for release third quarter 08.

--- so ends the first tale ---
Bob for the FlukeView Forms development team.

We saw two primary use cases.
1) Where a user was completing a printed form by manually entering meter readings, FVF was to allow that form to be created as a template and data taken directly from the meter into the form.
2) Where the goal is to either find and document an intermittent in the equipment under test - or provide documentation that no intermittent was detected.

In addition to that I would use it to learn the equipment I am working on. Saving the data for further review and analasys.

You know it just stuck me , but would it be possible to have a video with a new release, showing us how to use it and using to it maximum potential.
You know the old saying holds true, monkey see monkey doo .

Installment 2: Auto Detection of meters
The initial FVF talked to the Fluke 89 thru a serial to IRDA adapter plugged into a 9 pin com port on the PC. FVF had to be told (the first time) which com port it was to use. After which, FVF would on start up, open that communications port and try to communicate with the meter. If it found the 89, or found a different 89 than it had been talking to a minute ago, it would prompt the user to get meter data? On OK it would upload all of the data from the 89 – one set of individually saved readings, and one logging session. The data was then automatically copied to the form for display.
That was the vision – plug in the meter, ok the dialog and view the results.

Dial it forward to today. FVF supports 13 instrument families. The vision remains – plug in any of the meters, FVF should detect it, and if it supports stored readings, prompt to get meter data, uploads the most recent set of data and copies it to the form.

Most of the meters now connect through a virtual com port as opposed to the old 9 pin serial port.
Windows (not FVF’s) handles detecting USB devices. The first time it finds ‘new hardware’ Windows prompts with the familiar ‘search for drivers’. These drivers map the usb device to a virtual com port, assigning the com port number based on the next unassigned port number.

The auto detection scheme works as follows: We open the designated com port and attempt to communicate with the last meter family we had found. If it’s not there, we will attempt to talk to the next family type about a second later. We loop through all of the family types in this fashion in the background continuously until we find a meter. Disconnect your meter and the process will start again.

The auto-detection scheme evolved with the 3.3 release to be able to detect the Fluke 568 which utilizes the Windows HID (human interface device – like keyboards and mice) interface instead of virtual com port drivers. If the 568 is turned on and connected to the PC, it will appear in the Options/Communications dialog as “Fluke 568 (1)” where (#) is used to differentiate instruments if multiple 568’s are detected.

Like the 568, virtual com ports are only seen by Windows if the device is plugged in. If you last communicated with your 289 on Com3: and you start FVF without the USB/IR cable plugged in, Windows report that there is no COM3. If you start FVF, it will attempt to open com 3 and fail. We will display the Options/Communications dialog showing that com3 is selected and that it’s status was “Com3 not detected” . Pressing “Enter” will keep that selection and return to FVF. We will continue auto detection in the background such that when you do plug in the cable, we will succeed in opening the port and look for the meter itself.
--- so ends tale 2 ---

Is there a tale about dumping the meter(s) memory into a temp file? So that having to reconnect multiple times to the meter is a thing of the past? Maybe an option to delete temp files when fvf closes " if " desired . That would be a time saver for people on the go. Having to work with multiple files is a drag.

The 54 Series works a bit differently! It's been a while since I've logged with one but as I remember, you can log, stop and resume where you left off. Of course, you only have one parameter, temperature.

__________________
Bill

Thank you ivancaicedo237 - the 975 was the first of the 13 meters that supported uploading individual logging sessions. The 289 the second. I hear you, the ability to select multiple (or all) sessions - with some batch action - would be a nice addition.

WPTSKI, you are correct, the 54 is a bit different. You can indeed save individual readings, and start and stop logging as you will. And - all of the data is uploaded in one command. FVF thus gets all the data at once. It breaks the data into 'sessions' based on a number of factors in the data. The user gets to override that breakout by selecting any of the readings, or all of the readings to copy to the form. The fact that all the values were temperature readings allowed us to present the data as both logged readings, and as individual "displayed readings" as the user decided best fit the application.

The 1653 and 983 uploads are treated similarly with FVF presenting the data as sessions based on user settings within the data.

Hi,

I have a couple of questions/observations after playing around with my 289 and FVF, I'm not sure if you can comment on them or not, but here they are!

#1 - It took me 17 minutes to download 10,000 readings. Is this normal? I didn't see a way to change the baud rate of the port.

#2 - The FVF database (ms jet) format seems to really take up a bunch of room on the hard disk. I realize that it is both forms and data, but it seems to also have a "temp" area which also holds data even when the app is closed down. It is a pain to have to go to the designed to optimize the database. An option to optimize the database automatically on exit (and clear unnecessary tables like temp) would be idea. If I have a whole bunch of FVF's on my drive, they would add up quickly.

#3 - It would be great to do all the functions that you can on the regular graph in terms of cursors, etc., on the zoomed in full screen view as well.

#4 - Does anyone know if the upcoming upgrade 3.4 be a free upgrade from 3.31 ?

Thanks,

Alan

Alan:

There is a "Check for Updates" in the Help drop down menu! So, it could be.

__________________
Bill

hate to say it but unlike other fvf's this upgrade isn't free.