My current RS485 adapters say that they support 32 devices on the bus, due to the load of the signal path. I have ordered a 4 channel adapter with one USB input but that one also creates 4 ports so not a single port.
What adapters are you using?
Will you disclose the use of other addresses so that I can use in in definitions ?
I have already updated the documentation.
I want to add a screen dump to the CNT-90 definition, but it's returning this:
;; COM5: Tx: <:HCOP:SDUM:DATA?.> 3A 48 43 4F 50 3A 53 44 55 4D 3A 44 41 54 41 3F 0A
;; #ScreenDump failed due to 0
The result if I enter the command from the command window are attached in a text file (wouldn't let me post it).
Do I need to strip the leading #43942? Something else?
Thanks,
Josh
I want to add a screen dump to the CNT-90 definition, but it's returning this:
;; COM5: Tx: <:HCOP:SDUM:DATA?.> 3A 48 43 4F 50 3A 53 44 55 4D 3A 44 41 54 41 3F 0A
;; #ScreenDump failed due to 0
The result if I enter the command from the command window are attached in a text file (wouldn't let me post it).
Do I need to strip the leading #43942? Something else?
Generally I would need a photo of the screen, the data and a description of the format, but it might not be strictly necessary in this case.
The issue is the extra 64 bytes. TC know how a BMP looks and can easily handle it, but the 64 bytes before it stops that.
I do not believe you can use readmath on this command, i.e. I have to add a option to the command to skip bytes.
TC uses a special read (deviceReadBytes) for these types of data, this read understand the 43942 and uses it to read the correct amount of bytes. I do not remember if it is supposed to have a leading #, but I will check.
https://lygte-info.dk/project/TestControllerFunctions%20UK.html#deviceWrite,_deviceRead,_deviceReadBytes,_deviceWriteBytes
I tried changing it to:
#ScreenDump std
deviceReadBytes(device, ":HCOP:SDUM:DATA?") ;also tried handle,
:readmath: replace(value,"#","");
But that still gives the same ;; #ScreenDump failed due to 0
Do you mean a photo of the device display, or a screenshot of the TC response from the command line?
Thanks,
Josh
I checked the code.
The # is supposed to be there.
It expect to read the data in 3 seconds or less.
I wonder if the 62 bytes header is part of the BMP format, in that case TC is supposed to accept it
The return value you show looks very strange: 3A 48 43 4F 50 3A 53 44 55 4D 3A 44 41 54 41 3F 0A
I have not translated it to letter to see what it says, maybe there is a clue there.
Do you mean a photo of the device display, or a screenshot of the TC response from the command line?
I mean the display, but that is mostly relevant if I have to add a new decoding algorithm.
For now it can handle standard image formats and a specific DMM that has a special screendump format where I had to write a decoding algorithm.
The #screendump tag calls the deviceReadBytes function with the specified command.
If it fails at decoding the data it is supposed to dump a exception to console, but that will only happen if it try to decode a image.
You use this format:
#ScreenDump std
:HCOP:SDUM:DATA?
Do you mean a photo of the device display, or a screenshot of the TC response from the command line?
I mean the display, but that is mostly relevant if I have to add a new decoding algorithm.
For now it can handle standard image formats and a specific DMM that has a special screendump format where I had to write a decoding algorithm.
The #screendump tag calls the deviceReadBytes function with the specified command.
If it fails at decoding the data it is supposed to dump a exception to console, but that will only happen if it try to decode a image.
You use this format:
#ScreenDump std
:HCOP:SDUM:DATA?
That's how I had it originally. I added the deviceReadBytes stuff to try and use readmath- not that it matters since the # belongs there.
I attached an image of the display. It's not particularly exciting.
Thanks,
Josh
That's how I had it originally. I added the deviceReadBytes stuff to try and use readmath- not that it matters since the # belongs there.
The only way to get access to the deviceReadBytes() is in the other menu where you do the coding, there you can also add printLog() statement to see what you receive.
I attached an image of the display. It's not particularly exciting.
It shows it is a two color display. Do it use network or serial communication? My 3 second timeout may be an issue if it is serial.
It shows it is a two color display. Do it use network or serial communication? My 3 second timeout may be an issue if it is serial.
It's GPIB communication. There is a variant with Ethernet, but I don't have that.
#metaDebug only works after the first #metadef in a definition.
This is not mentioned in the documentation:
https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html##metaDebugHow do I save the second #metadef without having to comment out the first section ?
The first:
#metaDebug on Eletechsup NT48A08
#idString Eletechsup,NT48A08,
#name Eletechsup NT48A08
#handle NT48A08
#metaSection Chan20 --Exclude--
#metaSection --Include--
#metaSection Chan8 --Include--
#metaSection Chan20 --Exclude--
#metaSection --Include--
#metaSection Chan20 --Exclude--
#metaSection --Include--
;; jSerialComm version: 2.11.2The second:
#metaDebug on Eletechsup NT48A08
#idString Eletechsup,NT48A20,
#name Eletechsup NT48A20
#handle NT48A20
;; jSerialComm version: 2.11.2
It's GPIB communication. There is a variant with Ethernet, but I don't have that.
GPIB may be the issue, I have not tried binary communication through a GPIB interface and in this case we are talking a single message that is a few kb long and may contains EOL characters.
#metaDebug only works after the first #metadef in a definition.
This is not mentioned in the documentation: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html##metaDebug
Are we reading the same definition: "This is a debug tag that can be placed on the line after a #metadef tag"
How do I save the second #metadef without having to comment out the first section ?
You can only have on "#metaDebug save" at a time, you need to comment the other ones out.
I would rephrase into "This is a debug tag that can be placed once after the first occurrence of a #metadef tag"
I would rephrase into "This is a debug tag that can be placed once after the first occurrence of a #metadef tag"
It can be placed after any #metadef tag.
Yes, but if I place it after the second metatag, it does not output the debug information on the log, like I showed on my example.
My example only one metaDebug was active.
Yes, but if I place it after the second metatag, it does not output the debug information on the log, like I showed on my example.
My example only one metaDebug was active.
I just tried it in my test definition, add 3 #metadef (3 was empty)
Then did 3 runs with "#metadebug save" place on the line just below the 3 #metadef
Each time I got a list of changes and a saved file of the generated definition.
I also tried placing "#metadebug" without save in all 3 sections and got changes for all 3 sections in one long list with #metadebug section heads.
You must place it on the line just after #metadef to get all changes.
I hope you are looking at the console output, not in the log window!
You can email me you definition if you want me to take a look at the #meta stuff.
The email is if you want to avoid posting preliminary definitions here.
I will mail you my development version. You can see that de #sections do not work when it's the second #metadef.
Yes, console output.... my main screen during coding of definitions !
Mail is sent !!
I will mail you my development version. You can see that de #sections do not work when it's the second #metadef.
Yes, console output.... my main screen during coding of definitions !
Mail is sent !!
It toke me some time to realize what the issue was, but here is the explanation:
#metadef
#metadef filename without path and extension
#metadef device name
#metadef has 3 formats, internally the first format is replaced with #metadef filename and as filename is using the name of the file with the definition (of course), but in your case it also matches a device name and TC uses the device as basic for the second and third definition, not the intended definition file.
Knowing this, the fix is easy: Change the filename of the definition.
I changed my file from into Eletechsup NT48A08.txt into Eletechsup NT48 series.txt and with success.
Starting
#metaDebug on Eletechsup NT48 series
#idString Eletechsup,NT48A20,
#name Eletechsup NT48A20
#handle NT48A20
#metaSection Chan20 --Include--
#metaSection --Include--
#metaSection Chan20 --Include--
#metaSection --Include--
#metaSection Chan20 --Include--
#metaSection --Include--
#metaSection Chan20 --Include--
#metaSection --Include--
#metaSection Chan8 --Exclude--
#metaSection Chan20 --Include--
#metaSection --Include--
#metaSection Chan20 --Include--
#metaSection --Include--
;; jSerialComm version: 2.11.2
It was not only that the #metaDebug did not work, it was also affecting the #sections and #metaSection as you know.
Well I am glad that is resolved...
I changed my file from into Eletechsup NT48A08.txt into Eletechsup NT48 series.txt and with success.
It was not only that the #metaDebug did not work, it was also affecting the #sections and #metaSection as you know.
Well I am glad that is resolved...
I had forgotten all details about how TC handled the actual #meta stuff and had to find that out first, now I know again
TC scans all definitions and saves everything with #meta and #metadef in some special buffers, when all files are processes it starts on the list of #metadef it has saved. These are processed and scanned, then added to the loaded devices and remove from the #metadef list. When the #metadef list is empty, the loading is finished.
When a definition is going to be used, a full parse of it is done and it is not just loading that triggers a full parse of a definition.
One problem with the saved meta is that some character codes get converted wrongly.
Source:
#value TempCH20 °C D1 Temperature
#value OhmCH1 kΩ D2 Resistance
Meta after save metaDebug
#value TempCH20 °C D1 Temperature
#value OhmCH1 k? D2 Resistance
The Ω sign gets screwed up. My file is encoded UTF-8-BOM.
One problem with the saved meta is that some character codes get converted wrongly.
#value OhmCH1 kΩ D2 Resistance
#value OhmCH1 k? D2 Resistance
The Ω sign gets screwed up. My file is encoded UTF-8-BOM.
I do not remember if the output file is in unicode, but probably not.
What count is the units in TC and if the file has a BOM marker TC will read it correctly, another way is to use unicode escapes \u0000
My current RS485 adapters say that they support 32 devices on the bus, due to the load of the signal path. I have ordered a 4 channel adapter with one USB input but that one also creates 4 ports so not a single port.
What adapters are you using?
I use a CH340T + Max485 USB-A male, a FT232RL + Max485 USB-B female and a new 4 channel CH344 + Max485 USB-B female in on the way to me. If you want I can give direct links.