Netlinx - Control a Device - broke
GSLogic
Posts: 562
After many hours, I thought I would give a heads up to someone else!
If you try to send a hex command from Netlinx (ver 2.6.0.191) to a device using "control a device" and the command has $00 in it - it won't work. This really sucks for me as I do a lot of programming over the internet - long distance.
If you try to send a hex command from Netlinx (ver 2.6.0.191) to a device using "control a device" and the command has $00 in it - it won't work. This really sucks for me as I do a lot of programming over the internet - long distance.
0
Comments
Why should us poor programmers have to WASTE time finding problems that are already known?????
How about Telnetting the command?
What David mentioned is sad but true - most companies do think it's better to hide the problem until they fix it. Funny! sounds a lot like my son, when he breaks something he hides it too!
http://www.amxforums.com/showthread.php?t=3350
No-one wants fame or fortune for finding busted bits like this...we just need them fixed - or to at least know they will be fixed v soon!
The 35 hours we do every day are hard enough already, and finding faults and documenting them into a useful form takes time - I could list several instances where exactly this procedure has been fed into the proper pipes and I've never heard another sound about it.
The url above is a perfect example. This particular one is so wrong, it just has to be being fixed.....but I have no way of knowing that! Should I write it down again perhaps Should I send it through the right channel again perhaps?
Sometimes I feel like I should just email myself the fault report.
:-(
fnPositiveSpin()
{
As Gary suggests the page could be as simple as identifying issues that are 'being investigated' or 'known issue' or 'being corrected in rev x' etc. This would be really useful.
Return = cThreadTopic
}
When sending hex strings using Control a Device, i captured the string using Docklight on my laptop.
What happend:
Hex strings are sent as ASCII strings(!)
i have never seen this before, so it must be introduced in a newer version of Netlinx Studio...
I'm building/debugging a new module for nec 2150 series vp - think it runs the pixelworks chipset.
Manwell says:
This command acquires the operation mode of the projector.
Command:
00H 81H 00H 00H 00H 81H
Response: At the time of a success
20H 81H 01H xxH 01H DATA01 CKS
So I code a bit of stuff and build my lookup table to parse the buffer but it isn't working.
NSX diagnostics lets me know this useful load of cobblers.
String From [5001:1:1]-[ $81$00$10$01$00$B2]
How very lovely, except that the first byte is missing altogether - $20. Another printable char issue - space.
...and as for this gem...
String From [5001:1:1]-[ $81$00$10$01$A0R]
no $20 visible and possibly now just more printable chars being given to me instead of the hex at the tail.
I'm writing in hex. All I want back is hex. Just like the box sends it. No other flavor, just hex.
/grumpy
The following 3 strings will be sent down the wires in EXACTLY the same fashion.
SEND_STRING dvComm1, ??cat?? //ASCII
SEND_STRING dvComm1, ?$63,$61,$74? //HEX
SEND_STRING dvComm1,?99,97,116? //Decimal
The bits will wiggle the data lines exactly the same. Ignoring start/stop/parity bits and ignoring the timing, the transmit data line will produce the following.
01100011 01100001 01110100 //Binary
When that stream of 1?s and 0?s arrives at its destination, the receiving end determines how to present the data. Netlinx Notifications by default shows all printable ASCII characters and the unprintable are displayed as $xx. If you are watching Notifications while data is sent out the Netlinx comm port, the same rules apply.
I agree that there should be an option do view ALL bytes as HEX (or decimal is that?s your fancy.) just like any standard RS-232 capture program offers.
to view all caracters is, as you said, to use a RS232 capture program. I use one juste several days ago, because i had the same issue. The diag and notification over NS didn't want to show me all caracters. And i had no documentation for the protocol used for this old conferencing systeme.
So i tried "Docklight" a useful free software with some limitation if you use it as freeware but doen't mind it's working fine.
You can select the way you want to work : spy or direct link, and to display caracters, ascii, hex, bin...
And about this "issue" of NS display, i tried a lot of things to understand what the conferencing system send to me... printing all buffer, using temporary variable etc... and the only way to see all caracters was to use Docklight! The conferencing system i used was sending a lot of $00 and i never saw it. My NI3000 worked with it but didn't display it!
right...
if i choose to view incoming data as ASCII, and i'm sending out "$68,$65,$6C,$6C,$6F" using "control a device" i expect to see 'hello' in Docklight, not '$68,$65,$6C,$6C,$6F'
Assuming you have the String Expression checkbox checked when using Control A Device. If you don?t then the results you received are as expected. I used HyperTerminal to monitor NS2 v2.5 0.163 and v2.6.0.191 Control A Device and I don?t see the problem you?re describing, at least with the setup I have here. If I don?t have the checkbox checked then I see exactly what you see.
I see that problem here also, however, only with NS2 v2.5.0163. Control A Device is a NULL eater. It will send out the entire string sans any NULLs.
I did some tests with v2.6.191 and it looks like the NULL eater monster has been killed, as it looks fine from my end.
Sent out with Control a Device v2.5.0163:
"$68,$00,$65,$6C,$6C,$6F"
Received with HyperTerminal
hello
Sent out with Control a Device v2.6.0191:
"$68,$00,$65,$6C,$6C,$6F"
Received with HyperTerminal
h$00ello
We live in a programmers world though using programming environments such as NSX, so I don't want another application to show me what my programming app really should.
Printable or non-printable chars... I don't care. NSX has a responsibility to show data to us as it was presented to us. If the NEC spits out $20, show me $20 not a space.
Just because NSX shows me a space and not $20 does not make it right by any means. The NEC box spat out $20 (regardless of the fact is has an ascii or binary equiv), and I want to see it.
In my opinion this is a significant bug that needs fixing.
That fact that others are now launching other apps to monitor serial data simply proves my point.
NSX is an fantastic programming environment and hopefully if bugs like this get removed, one would easily consider it awesome.
erm?? they are the same thing. See Joe's reply earlier.
Unfortunately in NSX we cannot choose to view the incoming data in the format we desire.
NSX will convert everything to ascii if available and show everything else in hex format pre-pended with $.
The problem with this arises when the device is sending an ascii $ :-P
Other programs I use give an option to view incoming data as either Ascii, Hex, Decimal, Ascii/Hex mixed and so on.
At the end of the day this should really be a feature request and is not really related to the OP who was having an issue with trying to send data.
It should display it purely in one format or another, not a mixture. I understand the reason, but frankly, that doesn't make it right. What it does is an absolute pain.
The example I quoted above is probably as bad as it gets. Space. When the text is so small a space can easily slip past. If NSX displayed $20, there would be no issue.
That's exactly what I am saying NSX should do. Mixing display methods simply shouldn't happen.
:-)
Try the 'CHARDM' command on the port. I've had success with 20 millisecs.