Det är absolut inte onödigt att posta koden som orsakar felet, det är ju nödvändigt för att hitta vad du gör fel och utesluta attt det ärdin kod. (För vad skulle det annars vara?)
Du behöver dock inkludera varifrån hex_file och sno kommer dock
Jag gjorde en entry point i filen så jag kunde anropa den från Terminalen. Då kunde den s.a.s rapportera vad som var fel på ett annat sätt och jag kunde sätta print(xxx) som debugutskrift. Anropande program (Labview, kan inte hantera print() med den metod jag använder för tillfället.) Det visade sig att den ena parametern innehåll en path och med den kom backslash. Det var felet. Fixade iordning py filen och ändrade parametern så path hade forward-slash. PY filen började programmerade målet. Mycket bra tänkte jag.
Gick tillbaks till anropande program (Labview) och lade in ett filter som bytte alla backslash mot forward-slash. Testade. Funkade!!
Gick tillbaka till labview koden och satte en label 0.3.06 som är en versionsbenämning. Då såg jag att jag satt backslash utbytet på fel parametar - det innebar att py-filen fick ändå backslash i parametern men ändå funkade.
Där är jag nu. Det funkar. Åtgärden gjorde ingen nytta och det funkar ändå. Jag blir galen.
Hur som helst. Anropen till den api-funktion som programmerar har två parametrar. int(sno) och int(4000). Det sista är prog.speeden.
edit: Jag tror jag ska byta ut Labviews modul som är skapad för att anropa PY-skript mot ett terminalobjekt. Labview har ett Terminalobjekt som tar emot kommandosträngar typ "Python pytonscript.py param1 param2". Sen har den en stdout. Den terminalen är ärligare. Jag vet inte riktigt vad modulen som Labview har speciellt för att anropa PY-script har för sig under huven.