0

5520 FSC and S6 MOD3

Hello

We're in the process of moving from .proc to .PXE. To make it as painless as possible we utilised the "automatic build and compile" functionality by creating new project and selecting multiple pocedures.

But it's not as easy as we had hoped. Every procedure that is written with the 5520 FSC and have S6 in MOD3 generates an error "E4068: FSC 5520: LINE 156: MOD3 cannot be   S6  ,   ZM  , or   OM   unless option 5500A-SC600 or option 5520A-SC1100 is configured." and wont compile/generate the .PXE

 

We have a 5522A with 600MHz Scope option and the instument is configured correctly. We can run the procedure just fine but not compile it in the Editor.

The error message is not misswritten here, it states 5500-SC600 and not 5520-SC600.

I have tried both Met/Cal 8 Editor 8.3.2.3 and Met/Cal Editor 9.0.0.712 with the same error message.

 

Have anyone else had this issue?

 

13 comments

Date Votes
0
Avatar
Dale Chaudiere

You need to attach/include an instrument configuration file containing a "Fluke 5520A" with option -SC600 or -SC1100 to each of your projects.  The instrument configuration file attached to the project will be used during build and the "just-in-time" compile at run time.

0
Avatar
Joakim Spångberg

Thanks. I will try that.

 

Do you know why the 5520 FSC with MOD3 differ from O_CAL when it comes to compiling/building? Since all the procedures written with O_CAL instead of 5520 have been compiled/build without errors.

0
Avatar
Dale Chaudiere

Strictly historical.  The 5500, 5520, 5700, and 5720 are "Legacy" columated, cryptic instrument FSCs.  The 5502A, 5502E, 5522A, O_CAL are NVI (name = value) instrument FSCs.   None of the NVI FSCs should require an instrument configuration attached to the project.

We were able to delete the intrument configuration entry requirement for a number of Legacy instrument FSCs, but not for the 5500A and 5520A Oscilloscope Calibration Options.  For example, a 5700 FSC statement with MOD3 = "W" (Wideband AC Option) in the past would not compile unless "Fluke 5700A" was configured with the Option 03 selected.  This is no longer a requirement.

0
Avatar
Joakim Spångberg

I added our config.dat to the projet. It contain among other instruments our 5522A: (right click on the Project -> Add -> Existing item).

 4, @5522a, @O_CAL, @552x : Fluke 5522A (S6) { 5522A_1955906 }, Fluke 5500A/COIL { 5500A/COIL_84030016 }, Datron 9100 Opt200 { 9100 }

But I am still geting the error when compiling/building the project.

I also tried to copy the instument config file from a downloaded procedure (Agilent DSO5012A 1 Yr Ver IEEE using 5522A+SC600_20160425, config_5522a_sc600.dat) and added it to my project but it did not work either.

I also tried switching from 600MHz to 1100MHz Scope option, both in our config.dat and in the file added to the project but with the same result.

Is there somewhere else in the project properties/settings I need to include the file?

0
Avatar
Dale Chaudiere

If the procedure is using the 5520 FSC, the instrument configuration attached to the project must have "Fluke 5520A" configured with the S6 or G1 attribute.  The workstation instrument configuration file on the other hand must contain the instrument actually used at run time (e.g. "Fluke 5522A").  To say it another way, the build and run time just-in-time compile does not "Device Map".

0
Avatar
Michael Schwartz

I am SO GLAD I stopped using the instrument based FSC years ago!  
I write all my code for the standards using a driver with IEEE calls.   So much easier than fighting with the MET/CAL Compiler and the Configuration File.   The worst was the 9500 FCS with the sensors heads.

I should write a paper on just my MET/CAL based driver model someday.
But here are two related ones

http://www.callabsolutions.com/implementing-a2las-new-budget-requirements-for-electrical-and-rf-uncertainties-in-fluke-metcal-procedures/#more-288 

http://www.callabsolutions.com/using-fluke-metcal-to-implement-a-flexible-measurement-driver-model-with-expanded-measurement-uncertainties-and-error-checking/#more-304

Mike

0
Avatar
Michael J.

The new NVI FSCs are quite nice and very easy to use (way easier than setting up drivers and IEEE calls in my opinion). By example, the 5502A FSC will control 552xA and 550xA calibrators equally and the inputs are all actual words, like Voltage=5V or Operate and Standby.

0
Avatar
Michael Schwartz

Michael, I agree 100% Volts= 5 is much better way to program.

We started doing Name Values back in MET/CAL 5.0 in the 1990's.  But our standards was
Math S[30]="Volts= 5, Frequency= 1e3, State= On"
Call The Configuration Driver

The biggest difference was that if I wrote the code for a Fluke 5500A. Using this method  I could use it with any of the following standards:
Fluke 5500
Fluke 5502
Fluke 5520
Fluke 5522
Fluke 5700
Fluke 5720
Wavetek 9100
Wavetek 4808
Transmille xxxx
This list just goes on and on

Name Values pairs are great, but if they are on a 5502A FSC line, then they only work with the 5502A. 

I am a radically different programmer.  Name Value Pairs on a Command Line (ie S[30]) was radically different back in the 1990's.

Back in like 2002 gave the guys at Fluke an amazing idea how to restructure the code to support flexible drivers 100% across the board.  They said it would be too hard for most programmers to understand.  But, I don't think they really understood what I was thinking.  So, I just decided to do my own thing, now I think I have pushed MET/CAL to its absolute limits. 

Mike

 

0
Avatar
Joakim Spångberg

Of course! Now I feel stupid. >.<

Adding a config.dat with  "4, @5520 : Fluke 5520A (S6) {}" solved the issue.

 

The procedures that I write myself I always use the NVI FSCs if possible. Much easier to write, read and debug.

 

Thanks for the help!

 

Is there a way to automatically add the config file to many projects and then have them built and published?

0
Avatar
Chad D.

Mike, I am glad that you found a solution that works for your needs of vending commercial procedures. Most MET/CAL users don't share the same need and prefer to use instrument FSCs that do the majority of the work for them with just a couple of lines in a MET/CAL procedure to handle multiple operations: instrument control, reference accuracy or even measurement uncertainty calculations, connection messages, etc. It is not necessary or feasible for most MET/CAL procedure authors to create their own driver system to replace what is already offered in MET/CAL's instrument FSCs. Another thing I think people tend to forget is the backwards compatibility MET/CAL has always offered with procedure code. The procedures that people wrote in MET/CAL version 5.0 in the late '90s still work today, 20 years later -- an eternity in the software world. If Fluke were to start MET/CAL over from scratch today, I'm sure we would do things very differently, but we have always carried the prime directive to not break existing procedures.

0
Avatar
Chad D.

Hi Joakim, the Fluke procedure team has built a folder full of instrument configuration files after copying our workstaton config.dat file. From there, we just open the Project and then drag and drop the config file into the Editor's Solution Explorer window to add it to the Project. The only requirement is that the file name starts with the letters "config" and end with ".dat"; you can have as many letters in between as you like so you can have a file name like config_5522a.dat or config_5730a.dat.

Once you have these in place, you can build the entire Solution, or even use the Editor's Tools > Automated Build menu to build an entire directory full of projects.

0
Avatar
Michael Schwartz

It is differently a difference software writing styles.   And many of my customers just want the drivers and training on how to write better MET/CAL Procedures. 

Fluke has done a great job with backward compatibility.  But one of the things I have learned from our driver-based model is we get both forward and backward compatibility.   Meaning we can support the new Fluke 5730A in just about any version of MET/CAL.  

Even something as complex as the Fluke 96270.  Just write a driver and bam, it is now supported in older versions of MET/CAL as-well-as all of our Spectrum Analyzer Procedures.  And with very little man hours of software work.

I have this slide in most of training and presentations. "Better, Cheaper, Faster!"  Automation made calibration Better, Cheaper, Faster!.  Now the challenge is how to create, support and maintain all of that Automation "Better, Cheaper and Faster!"

Mike

0
Avatar
Joakim Spångberg

Yes, that is how I did it. But it would have been nifty with a "Batch Publish Package..." or do people generally use the .pxe from the project bin folder?

We're having a separate folder/drive with the .pxe files from finnished/completed projects. Should a procedure need to be updated we open it from our project folder and then publish the .pxe to the directory for finnished/ready to use procedures. 

Please sign in to leave a comment.