Something else, I like the text field behavior for this better. With it set as number, it hides the +/- sign. As text, it works perfectly and always shows as +/-.
If you don't mind, let's keep it this way.
Proposed final attached.
Thanks,
Josh
Something else, I like the text field behavior for this better. With it set as number, it hides the +/- sign. As text, it works perfectly and always shows as +/-.
If you don't mind, let's keep it this way.
Proposed final attached.
You write the definition, I will not enforce a specific way. I will suggest what matches the intension and most definitions for TC.
I see TC as a tool and not everybody uses it the same way, I try to accommodate most people.
I believe your definition is a very useful addition to TC and if you publish scripts to do sweep measurements it will be even better. I have a page for user scripts on my website.
I have not even commented on your freq setting, the normal TC way would be to specify the range as 10M to 6G and let the user add the M to each input value.
the normal TC way would be to specify the range as 10M to 6G and let the user add the M to each input value.
The device functions as 10M to 6000M. Doing it differently would be inconsistent with the device, and require translating 1G to 1000, 2G to 2000, etc.
I'd prefer it your way too, but keeping consistent with how the device operates is what I went with.
Thanks for all your help!
I will try to make a script, but first I need to add either my SMIQ (06B) or SML (03), or maybe both to TC. I'll probably try the SMIQ first since that one can actually do the full frequency range of these power meters.
Thanks,
Josh
Ok, I had a crack at getting it working with the QM1462 by modifying an existing example but couldn't get it to display anything in the "Current Values" tab.
After copying the driver file I modified "DigitechQM1462.txt" to the Devices folder, QM1462 comes up as an option in the "Load Devices" and I connect it to the existing USB com port, then I hit reconnect but nothing seems to happen.
I have verified there is the 14 byte data coming in on the com port with a terminal program.
Attached is the driver file and protocol description.
Any pointers please?
Ok, I had a crack at getting it working with the QM1462 by modifying an existing example but couldn't get it to display anything in the "Current Values" tab.
After copying the driver file I modified "DigitechQM1462.txt" to the Devices folder, QM1462 comes up as an option in the "Load Devices" and I connect it to the existing USB com port, then I hit reconnect but nothing seems to happen.
I have verified there is the 14 byte data coming in on the com port with a terminal program.
Attached is the driver file and protocol description.
Any pointers please?
It looks correct, except this format specification:
#dataFormat length firstByte firstByteMask
Stick a ; before it!
AUTO is not a valid range, but I believe TC will ignore it.
You might need a #rangeAC and #rangeDC, i.e. without a space
And run TC in debug mode when testing a new protocol, it usually makes it easier to see what goes wrong.
Ok, thanks a lot.
The debug mode helps, I had too many bits in the Byte 13 definition as well.
After I fixed that other wierdness was happening such as displaying wrong range as I rotated range knob so I guess that definition document for the tp4000zc protocol doesn't match the QM1462 exactly, so I'll keep looking into correcting all that.
Thanks for your help, will update when I get it sorted.
Ok, I've sorted the range things and I've checked the bytes for the seven segment data and it looks correct.
When I change to the Current Values tab, from the command window (see attached) it looks like TC trying to send something to the meter and expecting a response (these meters are send only) which I guess TC doesn't receive and maybe then just displays infinity in the current values tab.
Ok, I've sorted the range things and I've checked the bytes for the seven segment data and it looks correct.
When I change to the Current Values tab, from the command window (see attached) it looks like TC trying to send something to the meter and expecting a response (these meters are send only) which I guess TC doesn't receive and maybe then just displays infinity in the current values tab.
The TX is to the meter driver, not the meter. Internal TC converts all devices to a sort of SCPI with its drivers. You can see the Tx only goes to the QM1462, not the com port.
This driver runs in the background and catches all communication, a read request will be answered with the last captured value.
Ok, thanks, not sure why it reads infinity for the value then, I'll keep digging.
Ok, thanks, not sure why it reads infinity for the value then, I'll keep digging.
It is the default answer when it fails to decode the value.
If you get stuck, send me the bytes as a hex dump together with the meter reading (No screen shoot, the bytes has to be as text) and your current definition, then I can look at it. But I do not have time today.
Ok, thanks, I'll dig deeper tomorrow and if I can't sort it will send you the info.
Cheers and thanks greatly for your assistance.
Off to a good start. I thought it would be more annoying to connect this one.
So far just the barebones:
#idString Rohde&Schwarz,SMIQ06B,
#name R&S SMIQ06B
#handle SMIQ06B
#port com 5025 LXI GPIB
#baudrate 115200*idn?
;; SMIQ06B: Tx <*idn?>
;; SMIQ06B: Rx <Rohde&Schwarz,SMIQ06B,XXXXXX/XXXX,5.93HX >
;; Rohde&Schwarz,SMIQ06B,XXXXXX/XXXX,5.93HX
Wow, this one is so much simpler with SCPI available. I just guess at crap, and it works. FREQ 500MHz, done. FREQ? works, etc. etc.
I've run into a small issue...
#cmdSetup number Step_Size_Log Freq_Sweep
% 0.01 50
:read: SWE:FREQ:STEP:LOG?
:write: SWE:FREQ:STEP:LOG #
:updatealloff:
:tip: Enter log step size for sweepThis functions correctly, but shows the numbers awkwardly. The range is 0.01% to 50%, but TC shows 0.01% as 10m. 10m% is a little weird. 😉
Thanks,
Josh
PS. This is the range for the other one:
#cmdSetup number Step_Size_Lin Freq_Sweep
Hz 0 1G
Don't blame me for that 1000M 😉😉
Thanks! :format: x2 is perfect.
Thanks! :format: x2 is perfect.
Good.
Don't blame me for that 1000M 😉😉
And I will not blame your for this one, I first step to next SI prefix if the value is above 1000, but even a very small amount above will get your the next prefix. If you really don't like it you can specify something like 1.00000001G, but personally I prefer the 1000M
I was joking cause you teased me about the 6000M.
Is there a way to make each tab take up the full width so it looks more consistent?
Also curious if there's a way to make the border hug the edge of the full box, rather than shrinking to the content.
Thanks,
Josh
Is this the correct way to add a variant?
#metadef
#idString Rohde&Schwarz,SMIQ02B,
#name R&S SMIQ02B
#handle SMIQ02B
#replace #cmdSetup multi Freq_Range Frequency_Sweep
:read: :FREQ:START?;:FREQ:STOP?
:write: :FREQ:START #;:FREQ:STOP #
number Start Hz 300k 2.2G
number Stop Hz 300k 2.2G
:tip: Enter start and stop frequencies for sweep
#replace #cmdSetup number Set_Frequency Main
Hz 300k 2.2G
:read: FREQ?
:write: FREQ #
:update: Set_Frequency
:format: si
:tip: Enter the desired frequency
For the settings I included, the only thing that needs to change is the max frequency that can be entered for each variant.
One other question: can I combine similar variants, or do they need their own metadefs? For example: SMIQ02B/SMIQ02E
Thanks,
Josh
Is there a way to make each tab take up the full width so it looks more consistent?
Also curious if there's a way to make the border hug the edge of the full box, rather than shrinking to the content.
The answer is no to both and I have tried to fix number two, but did not succeed as can be seen.
Is this the correct way to add a variant?
No.
You declare your full definition #meta, i.e. add a line with #meta and nothing else before the start of the current definition. This will make it a abstract definition, that cannot be loaded or rather is loaded to a hidden place.
The your add a #metadef line for each variant above the #meta.
Below each #metadef you will typical need #idstring #name and #handle, in addition to any modification to the #meta section.
The original definition can be reintroduced with only a #metadef line, because everything is already preset in the #meta definition.
To replace a value the #replaceText is often useful, instead of writing the value in the #meta definition you use a unique word (Like Max_output_freq) and then each #metadef has a #replaceText to replace the unique word with the actual value.
So, uh, what did I screw up here?
#metadef
#idString Rohde&Schwarz,SMIQ06B,
#name R&S SMIQ06B
#handle SMIQ06B
#port com 5025 LXI GPIB
#baudrate 115200
#replaceText MaxFreq 6.4G
#meta
#idString Rohde&Schwarz,SMIQXXX,
#name R&S SMIQXXX
#handle SMIQXXX
#port com 5025 LXI GPIB
#baudrate 115200
Thanks,
Josh
So, uh, what did I screw up here?
#metadef
#idString Rohde&Schwarz,SMIQ06B,
#name R&S SMIQ06B
#handle SMIQ06B
#port com 5025 LXI GPIB
#baudrate 115200
#replaceText MaxFreq 6.4G
#meta
#idString Rohde&Schwarz,SMIQXXX,
#name R&S SMIQXXX
#handle SMIQXXX
#port com 5025 LXI GPIB
#baudrate 115200
That looks fine,
except you do not need to include #port and #baudrate in the #metadef when they are exactly the same as in the #meta
Ok, so what's breaking this file then? It works fine without the meta/metadef stuff, but once that's added, the SMIQ devices don't exist in the dropdown list on the Load devices tab.
Thanks,
Josh
Ok, so what's breaking this file then? It works fine without the meta/metadef stuff, but once that's added, the SMIQ devices don't exist in the dropdown list on the Load devices tab.
Try moving the #helpurl into the #meta section, instead of placing it before the #metadef