Communication with oscilloscope Hanmatek DOS 1102

[shell04]

Hi, 

I have the hardware (oscilloscope: Hanmatek DOS1102) and did not found any driver for this. So i tried to implement a VISA communication and SCPI commands.

Without success. Is there anyone who has the same problem and has established communication with this oscilloscope or found a driver? I am a LabViEW beginner and am grateful for any tip or VI.

Thank you very much.

[santo_13]

Please post what you attempted and your observations along with the programmer's manual.

Note: please attach VIs in LV2016 version to cover a wider audience (File > Save for previous)

Since you're a beginner, this video will be a good tutorial for serial communications.

https://labviewwiki.org/wiki/VIWeek_2020/Proper_way_to_communicate_over_serial

[shell04]

Enclose i have added the VIs.

Thanks for the response and the Video.

I hope there is a simpler solution for my problem 🙂

Thanks

[psuedonym]

---

@shell04 wrote:

Enclose i have added the VIs.

Thanks for the response and the Video.

I hope there is a simpler solution for my problem 🙂

Thanks

---

So what is the problem?

There isn't a "simpler" solution. If there isn't a pre-made driver, you have to write it yourself. This is what happens when you buy a hobbyist scope.

[shell04]

Sorry, I know there is no easier solution.

It was related to the video. That was a little too high for my level.

The problem is that I can't get any values out. I don't know how to display the graph from the oscilloscope and read values like max or peak to peak.
It is not showing me anything.

[psuedonym]

---

@shell04 wrote:

Sorry, I know there is no easier solution.

It was related to the video. That was a little too high for my level.

The problem is that I can't get any values out. I don't know how to display the graph from the oscilloscope and read values like max or peak to peak.
It is not showing me anything.

---

Getting the graph from the scope is not a trivial task.

Ask your boss to send you for some training.

I can't even find a manual for it. LOL.  

Good luck.

[geekodude]

Here is the manual for the Hanmatek DOS 1104.  Read page 16 and. see if you can get a hold of the software.  I suspect the driver will work with 1102.

[paul_a_cardinale]

Through trial an error, I have figured out the following:

:ACQ:MODE {SAMP|PEAK|AVE}
:{CH1|CH2}:COUP {DC|AC|GND}
:{CH1|CH2}:SCA <extened value (e.g. 100mV)>
:{CH1|CH2}:POS <value (divisions)>
:{CH1|CH2}:OFFS <value (volts)>
:{CH1|CH2}:PROBE {1X|10X|100X|1000X}
:{CH1|CH2}:INV {OFF|ON}

:HOR:OFFS <value>
:HOR:SCAL <extened value (e.g. 10ms)>
:TRIG {EDGE|VIDEO}
:TRIG:TYPE {SING|ALT}

:MEAS?
:MEAS:{CH1|CH2}:{PERiod|FREQuency|AVERage|PKPK|SQUARESUM|MAX|MIN|VTOP|VBASe|VAMP|
VPRESHOOT|PREShoot|RTime|FTime|PWIDth|NWIDth|PDUTy|NDUTy|
RDELay|FDELay|TRUERMS|CYCRms|WORKPERIOD|RISEPHASEDELAY|
PPULSENUM|NPULSENUM|RISINGEDGENUM|FALLINGEDGENUM|AREA|CYCLEAREA}?

But there are many that I haven't figured out yet (e.g. trigger source and level).

[rolfk]

---

@shell04 wrote:

Enclose i have added the VIs.

Thanks for the response and the Video.

I hope there is a simpler solution for my problem 🙂

---

One of the problems in these VIs is the standard problem of not understanding the differences in Display Style of string controls and constants. And this is actually explained quite detailed in the video from Tim Robinson aka crossrulz, linked to earlier.

First step is to right click on the constant or control and select Visible Items->Display Style. This option is available since at least LabVIEW 2018, but I think it was added around LabVIEW 2013. This shows a glyph on the left hand side of the string control or constant that indicates the current style. Your constant was in n=Normal mode:

Click on that little n with the select tool (or if you use an older version that does not support displaying this glyph, right click on the constant itself) and select '\' Codes Display. You will now see this:

What you can see is (besides that the glyph changed to a backslash to indicate what mode the string display is in) the \n changed to a \\n which means that the device will see a \ character followed by a n character, which it will not really be able to understand, followed by a \n (which is what caused the string to have two lines in normal mode), and which is the escaped notation for the <new line> character that will be send and there is nothing more at the end of the second command.

Serial devices must have a way to recognize that a command is finished and they should start parsing and interpreting it. That is usually done through the <new line> or <charriage return> at the end of a command. Which one it is depends on the device and needs to be documented (or found out by trial and error).

So your command will probably generate a device reset (or error if the parser doesn't ignore the bogus \ followed by n characters) and then nothing. Your device is still waiting for another <new line> character that tells it to parse the ":MEASure:FREQuency?" command in its buffer until forever! 

The string should look like this instead:

No bogus \\n and both commands are properly terminated with a <new line>. In normal mode it would look like this: 

But that should not be used normally, it hides the fact that there are important special characters like the <new line> in the command and makes reviewing the VI a lot harder. At least the visible glyph gives a hint to the informed person that there is probably more to that string than what meets the eye.