QLS 3600s functiegenerator: software verbinden lukt niet.

In een recente blogpost van Jos Verstraten https://verstraten-elektronica.blogspot.com/p/qls3600s-10m-10-mhz-func… heeft hij deze functiegenerator besproken. Ik heb het testmodel overgenomen, met als doelen om een simpele arbitrary-functie generator te hebben, en om deze via de computer aan te kunnen sturen.

In zijn blog had Jeever al aangegeven dat dit apparaat via een Labview app werkt, en dat hij dat niet wilde testen. Ik ben ook geen grote fan van LabView, maar ben wel bereid dat op mijn laptop te zetten.
Achteraf blijkt ook dat er niet veel over dit apparaat te vinden valt.

Helaas krijg ik op geen enkele manier respons van het ding.
- software gedownload via de link in de blog van Jos Verstraten, https://www.qletek.com/Upper%20Computer/QLS3600-C4.zip. Daar (b)lijkt de CH340 driver niet in te zitten (er is wel een directory voor maar die is leeg). Driver voor de CH340 heb ik apart gedownload.
- de LabView app crasht met een foutmelding van de LabView 'MemoryManager.cpp'

- dit zou wellicht iets met de 'localisatie' settings van de LabView app te maken kunnen hebben.

- de interface (CH340) is zichtbaar in de Device Manager
- Een deel van de specsheet geeft aan dat het apparaat een 'public protocol' heeft. Ik gokte op SCPI, maar krijg via "smart SCPI terminal (micro|free)" geen antwoord op een "*IDN?" request (timeout).

Wie heeft er een tip?

Uit "Google" rolt hier een Chinese PDF met wat een beschrijving van het protocol lijkt te zijn.

- Een deel van de specsheet geeft aan dat het apparaat een 'public protocol' heeft

Nee het ze bedoelen dat je dat protocol kan downloaden en inkijken.

Maar ik heb via google AI dat al voor je vertaald.
IK zou zelf labview overslaan en gelijk in testcontroller dat erin gaan zetten. testcontroller is een klein programma en zelf je eigen defenities maken kan ik je wel bij helpen. Als je wilt kan ik morgen een klein opzetje maken maar ik kan het dan niet testen.
Het is zeker geen scpi.

IN principe kan je nu met een terminal die voorbeelden hierondergewoon proberen

https://lygte-info.dk/project/TestControllerIntro%20UK.html
Dit is wensite van testcontroller en helemaal onderaan is een download.
Download is een zip file die uitpaken ergens neer zetten en verder hoef je aan testcontroller niets te installer gewoon de direct van die directie te gebruiken.
Testcontroller heeft wel java8 nodig en geen jdk of iets anders.

Voordeel van testcontroller is er dat er nu al echt heel veel definties zijn voor heel veel apparatuur.

### QLS3600 Signaalgenerator - Volledig Gedecompileerd Protocol (Baudrate: 57600) ###


=================================================================================
1: SCHRIJFCOMMANDO'S (Tx Matrix) -> Formaat: W + Functie + Parameter + s
=================================================================================

(1) WA0s t/m WA32s   -> Waveform selectie (Keuze uit 33 ingebouwde golfvormen)
(2) WB+frequentie+s  -> Frequentie instellen (Invoer Hz * 100 kogelhard!)
    * Voorbeeld 1000.00 Hz  -> 1000 * 100 = 100000     -> Send: WB100000s
    * Voorbeeld 2.00 MHz    -> 2000000 * 100 = 200000000 -> Send: WB200000000s

(3) WC+amplitude+s   -> Amplitude (Spanning Vpp * 100)
    * Voorbeeld 8.00 V      -> 8 * 100 = 800           -> Send: WC800s

(4) WE+dutycycle+s   -> Duty Cycle (Procenten * 10)
    * Voorbeeld 50.0%       -> 50 * 10 = 500           -> Send: WE500s

(5) WD+offset+s      -> Gelijkspannings-offset (Offset-waarde + 1000)
    * Voorbeeld +10.00 V    -> 10 + 1000 = 2000        -> Send: WD2000s
    * Voorbeeld -10.00 V    -> -10 + 1000 = 990        -> Send: WD990s
    * Maximale min-offset   -> Send: WD0s of WD000s (-10V limiet)

(6) WF0s t/m WF3s    -> Gate Time (Poorttijd frequentieteller: 0.01s, 0.1s, 1s, 10s)
(7) WG+sweep_start+s -> Sweep Startfrequentie (Hz * 100) -> Bijv. 10kHz = WG1000000s
(8) WH+sweep_eind+s  -> Sweep Eindfrequentie (Hz * 100)  -> Bijv. 100kHz = WH10000000s
(9) WR0s / WR1s      -> Sweep Modus -> WR0s = Logaritmisch, WR1s = Lineair
(10) WJ+sweep_tijd+s -> Sweep Tijd (Seconden * 10) -> Bijv. 5.8s = WJ58s
(11) WK0s / WK1s / WK2s -> Sweep Richting -> WK0s = Vooruit, WK1s = Achteruit, WK2s = Heen-en-Weer
(12) WL1s / WL0s     -> Sweep Control -> WL1s = Start Sweep, WL0s = Stop Sweep
(13) WM+burst+s      -> Burst Aantal pulsen -> Bijv. 100 pulsen = WM100s
(14) WN0s / WN1s     -> Trigger Modus -> WN0s = Handmatig, WN1s = Externe Trigger
(15) WO1s / WO0s     -> Trigger Control -> WO1s = Trigger AAN, WO0s = Trigger UIT
(16) WP1s            -> Handmatige Puls Trigger (Vuurt direct 1 burst af)
(17) WI0s / WI1s     -> Systeemtaal -> WI0s = Chinees, WI1s = Engels
(18) WQ1s / WQ0s     -> Beeper (Button Sound) -> WQ1s = Geluid AAN, WQ0s = UIT
(19) WS0s / WS1s     -> Functie-Keuze -> WS0s = Frequentieteller, WS1s = Pulsteller
(20) WT0s / WT1s     -> Meet-Modus -> WT0s = Meet Frequentie, WT1s = Meet Pulsbreedte
(21) WU1s / WU0s     -> Teller Control -> WU1s = Start meting, WU0s = Stop meting
(22) WV1s / WV2s / WV0s -> Pulsteller Acties -> WV1s = Start Teller, WV2s = Pauze, WV0s = Reset 0
(25) WW0s / WW1s / WW2s -> VCG Spanningssturing -> WW0s = Freq, WW1s = Amp, WW2s = Duty
(26) WX+vcg_start+s  -> VCG Startpunt (Hz * 100) -> Bijv. 10kHz = WX1000000s
(27) WY+vcg_eind+s   -> VCG Eindpunt (Hz * 100)  -> Bijv. 20kHz = WY2000000s
(28) WZ30s           -> VCG Start Calibratiewaarde (ADC Startwaarde)
(29) Wa5000s         ➔ VCG Eind Calibratiewaarde (ADC Eindwaarde)
(30) Wb1s / Wb0s     -> VCG Aan/Uit Grendel -> Wb1s = VCG AAN, Wb0s = UIT
(31) Wc1s / Wc0s     -> Output Switch (Hoofdrelais) -> Wc1s = LIVE AAN, Wc0s = OP ZWART
(32) Wf1s            -> Sla Systeeminstellingen op (Taal en Geluid)
(33) Wd1s            -> Sla Data-registers op in EEPROM
(34) We1s            -> Data-registers oproepen (Recall)
(35) Wg+puls_breedte+s -> Puls Uitgang breedte aanpassen (uS * 100) -> 10ms = Wg1000000s
(36) Wh+puls_periode+s -> Puls Uitgang periode aanpassen (uS * 100)  -> 20ms = Wh2000000s
(37) Wr0s / Wr1s     -> Puls Uitgang Control -> Wr1s = Active AAN, Wr0s = UIT

=================================================================================
2: LEESCOMMANDO'S (Rx Pijplijn) -> Formaat: R + Functie + s (Antwoord start met #)
=================================================================================

(1) RBs   -> Lees Gemeten Frequentiewaarde uit
(2) RCs   -> Lees Actuele Pulsteller-waarde uit
(3) RDs   -> Lees Positieve Pulsbreedte uit (Geeft bijv. #RD000000100000)
          -> Formule: Breedte = (Aantal_clocks * 0.625 / 100) us
(4) REs   -> Lees Negatieve Pulsbreedte uit
(5) RFs   -> Lees VCG ADC Spanning uit
(6) RSs   -> Lees Actuele Sweepwaarde uit

=================================================================================
3: ARBITRARY WAVEFORM DATA-INRUSH (Custom golven inladen)
=================================================================================
Resolutie per datapunt: 0 tot 1023 (10-bit DAC). Totaal verplicht 1023 datapunten!
Formaat: wb + Hex-adres (0 t/m F) + alle datapunten gescheiden door komma's + \r\n.
Dit moet 16 keer herhaald worden om het complete frame te vullen.

Voorbeeld (Rechte DC-lijn schrijven naar adres-slot 15):
wb15508,508,508,508,508,508,508,508......508,508\r\n

[Bericht gewijzigd door benleentje op (61%)]

Bedankt voor jullie input, kennelijk zijn mijn google-skills wat roestig....

een kleine waarschuwing, er staan op de qletek site kennelijk links (advertenties?) die NSFW zijn.....

De simpele string commands werken (beperkt getest).

TestController heb ik al eens gebruikt voor een ADS1256 projectje (gebaseerd op de library van Curious Scientist), dus dat komt goed!

Wellicht dat ik eerst een Python programmaatje schrijf (of beter, dat door ChatGPT laat doen).

Ik heb ChatGPT aan het werk gezet, die had binnen een minuut (!) een eerste, werkende versie van een besturingsprogramma. Er zitten nog wat schoonheidsfoutjes in (de verschillende waveforms zijn niet goed gemapt), maar in de basis werkt het.

Zo doe ik dat ook, ik schrijf geen regel code meer. Leg ChatGPT wel goed uit wat er fout is en hoe het moet, dan komt hij (zij?) daar ook wel uit.

In welke programmeertaal heeft chatgpt dat geschreven (/gegenereerd) ?

Ik heb ChatGPT gevraagd om de code in Python te schrijven. Dat heb ik vooral gedaan omdat ik zelf vaker Python wil gaan gebruiken, maar ook omdat de AI engines een 'voorkeur' lijken te hebben voor Python, tenminste voor dit soort simpele dingen.

Mijn tijd heb ik vanmorgen vooral gestoken in het opzetten van de 'toolchain' voor Python, en (gedeeltelijk) testen van het resultaat.

Let wel, dat is in mijn context: ik ben fysicus/ingenieur, en codeer zelf alleen voor dit soort zaken (testen, dataverwerking, uitgebreide berekeningen), nooit voor professionele productie code.

[Bericht gewijzigd door HarmP op (14%)]

Ah ja, dat is ook precies de hoek waar python veel toegepast wordt is mijn indruk. Best knap dat AI zo in een paar tellen een tooltje met GUI en al maakt.

Kennelijk heeft dit device gewoon USB CDC en een interface via Ascii.

Dat ze dan Labview software ontwikkeld daarvoor hebben is echt overkill. Ik was bang dat het USB TMC was, maar dat is het niet.

USB CDC en Ascii commando's worden gewoon door TestController ondersteund (TMC niet) dus als je met Python alles hebt uitgeplozen kun je daarna een definitie maken voor TC en kan je daar ook mee gaan loggen en grafieken maken.

Ik heb nu alles aan de praat. De arbitrary function generator kostte nogal wat kruim, dat kwam vooral door mijn onervarenheid met (gratis) ChatGPT. Die blijkt namelijk vrij snel aan geheugenverlies te lijden (zie hieronder). Hierdoor kostte het heel veel tijd voordat mijn suggestie ('de arbitrary geheugenbanken zijn doorlopend geadresseerd') door ChatGPT werd overgenomen.

De Python file is bijgevoegd (ongeveer 3000 regels....).

Screenshot van het 'arbitrary function generator' stuk.

Werken met ChatGPT:
Aan het einde van de sessie heb ik de volgende vraag gesteld, met bijbehorende antwoord.

Vraag: clarification about the use of ChatGPT: initially you could read the protocol PDF yourself. Later I needed to paste in part of the text. Did we reach a memory limit?

Antwoord: Yes — effectively, we ran into a context/file-content limit, but it wasn't quite a simple “memory limit.”
What happened was:
• Initially, the protocol PDF was available to me as an attached source, so I could inspect/search its contents directly and use the protocol details while modifying the Python code.
• As the conversation became longer and we went through several iterations of the code, not all of the earlier PDF content remained directly available in my active context.
• At that point, I could still work with the Python file, but I no longer had the same direct, reliable access to all of the protocol details from the PDF.
• That's why you ended up pasting the relevant protocol/log information. It effectively reintroduced the critical information into the current context.
There was an important consequence here: I made an incorrect inference about the address offset during those iterations. Your pasted logs were actually more authoritative for that specific behavior than my partially retained understanding of the PDF.
So, was it “memory”?
In practical terms, yes: context capacity.
It's better to think of it as a working context window rather than permanent memory:
Attached files + conversation + previous tool results + my current reasoning all consume context.
As a conversation gets longer, older material may no longer be fully represented in the active context. The underlying uploaded file isn't necessarily deleted; rather, I may need to retrieve/search it again rather than relying on what I remember from earlier in the conversation.
That's also why, in this latest debugging step, I went back to the actual Python source and found the original protocol comments again. The source explicitly says that the waveform addresses are 10–1F and that the command is wb + address + first sample.
One useful distinction
I don't have human-like persistent memory of the PDF. There are really three things involved:
1. Current context — what I can directly “see” right now.
2. Attached files — which can often be searched/read again when available.
3. Conversation history — which can become less directly accessible as the conversation grows.
So if we're doing a long technical debugging session with a specification PDF, a good practice is to occasionally say something like:
“Go back to the protocol PDF and verify this before changing the code.”
That forces the reasoning to be grounded in the actual source rather than relying on an earlier interpretation.
And in this case, your logs were extremely useful because they exposed the exact distinction between wb10..., wb40..., and the erroneous wb110....