An endless SRQle

Am trying to understand the nature of how Met/Cal handles SRQ's. I kind of get that when a query is sent, a reply is expected and Met/Cal checks to see if that reply is in accordance with what it was expecting. I get that. But I have an IEEE-488-1978 compliant device that asserts SRQ before the proceedure even begins. I am assuming this is in response the to the Clear command that Met/Cal sends out when the proceedure loads. But what I do not get is that this makes Met/Cal act stupid. Even ASK and DISP FSC's will not run because SRQ is high. Yet I don't see a solution to this. Why would a high SRQ on loading a proceedure cause the entire program to error on non-IEEE statements? Am I not understand what SRQ's are?




Dexter, I don't see responses


I don't see responses so I'll promote this topic as I am curious too.  My first thougt is that a high SRQ return is an indication of a UUT error, but we send commands to certain power supplies that reply with a SRQ message -  acknowledging by keyboard gets them to continue the procedure steps. 



Hey Dexter, SRQ have always

Hey Dexter,

SRQ have always confused me, but I think a new question that came up here today might give you a work around to avoid the errors at least: 


I saw that pop up! That's

I saw that pop up! That's very interesting! Espeically since I have been diving deeply into the metcal.ini file recently. (Fun fact, you cannot run Met/Track v7 when Met/Cal v9 is installed without having two metcal.ini files and swapping them in and out as needed). 


Why are you running 7 and 9

Why are you running 7 and 9 at the same time?


I actually amend my previous

I actually amend my previous comment. I can get Met/Cal v9 and Met/Track v7 to run at the same time. Just had to get creative with the ini file. As to why; we are transitioning. Well, technically we've been transitioning for about a year now but supposedly, in the next, maybe nearish, future we'll be running Met/Cal v9 and the newest version of Met/Team. But no one except maybe the lab supervisor has even a basic competency with the new software. So I was tasked with loading the new software on my PC (not at all an easy task with the draconian policies of our IT department and justifications for why I needed a SQL server running on my machine). My Met/Cal v7 editor got overwritten in the install. Not a big deal as my machine is merely used for procedure writing and development but I still need Met/Track as that's where our current database still resides. As an aside, Met/Cal Editor v9 is radically different than v7. Am having to relearn everything all over again. 


I just wanted to share a

I just wanted to share a reminder/suggestion with everyone on this subject. Running two versions of MET/CAL on the same machine is not a supported configuration and may cause problems. A safe way to evaluate new software is by using a virtual machine. Oracle VirtualBox and VMWare are popular options for evaluating and testing new or updated software before going live with it in a production environment. You can create a VM, install Windows, take a snapshot of it, install whatever you want and test it out, then capture another snapshot. The next time you need to test software, restore the original clean snapshot of Windows, and you are ready to install the next software and start evaluating again. You can move between snapshots very easily with software like VMWare, even switching between entirely different software configurations. It's great for testing like this.


Point well taken, though I'd

Point well taken, though I'd never get approval from IT to do that. It would require department head approval, IT approval, business justification, etc. (read: weeks to months). This, while not supported by Fluke (do not worry, I will not be spamming support if gliches arise) took me less than a day. It was a path of least resistence decision.