Home AMX User Forum NetLinx Studio

Netlinx - Control a Device - broke

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.

Comments

  • mpullinmpullin Posts: 949
    GSLogic wrote: »
    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.
    You're doing a Send String with String Expressions, or does your Command involve a $00?
  • GSLogicGSLogic Posts: 562
    mpullin wrote: »
    You're doing a Send String with String Expressions, or does your Command involve a $00?
    My command string has a $00 in the string. From what I understand, it is removing the $00 completely.
  • JeffJeff Posts: 374
    I had this same problem, but it also replaced every character after the $00 with $00
  • GSLogicGSLogic Posts: 562
    I REALLY think AMX should have a thread just for the AMX engineers to post known major issues they are working on.
    Why should us poor programmers have to WASTE time finding problems that are already known?????
  • DHawthorneDHawthorne Posts: 4,584
    GSLogic wrote: »
    I REALLY think AMX should have a thread just for the AMX engineers to post known major issues they are working on.
    Why should us poor programmers have to WASTE time finding problems that are already known?????
    This is typical; a lot of companies have similar policies. They don't like to announce they know about an issue until they have a solution. Often, you can get an individual AMX tech to spill the beans, but an official notices doesn't usually come until the problem is fixed. There are exceptions, but they are rare.
  • TurnipTruckTurnipTruck Posts: 1,485
    You could put the string in a variable that you could modify in run time in debug. I've pretty much stopped using "Control a Device" except for channel pushes and on offs.

    How about Telnetting the command?
  • GSLogicGSLogic Posts: 562
    I use "Control a Device" all the time - mainly with new gear - testing commands. Once I know what the client wants to control, I then test, then I build the command array.

    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! :)
  • DarksideDarkside Posts: 345
    GSLogic wrote: »
    I REALLY think AMX should have a thread just for the AMX engineers to post known major issues they are working on.
    Why should us poor programmers have to WASTE time finding problems that are already known?????
    Related issue, but a bit different to the thread topic....

    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
    }
  • yuriyuri Posts: 861
    i figured this out last week.
    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(!) :o
    i have never seen this before, so it must be introduced in a newer version of Netlinx Studio...
  • DarksideDarkside Posts: 345
    Never lost a $20 this fast

    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
  • Joe HebertJoe Hebert Posts: 2,159
    yuri wrote: »
    i figured this out last week.
    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(!) :o
    i have never seen this before, so it must be introduced in a newer version of Netlinx Studio...
    You?re choosing to view it that way by setting the preference in Docklight to view incoming data as ASCII. Netlinx Studio or the Netlinx comm port have nothing to do with it.
  • Joe HebertJoe Hebert Posts: 2,159
    I'm writing in hex. All I want back is hex. Just like the box sends it. No other flavor, just hex.
    HEX is merely a figment of our imagination. The box doesn?t send HEX. A comm port (any comm port including Netlinx) sends binary bit streams of logic highs and logic lows. A comm port doesn?t know about and doesn?t care about HEX, ASCII, or decimal, as it?s simply irrelevant since it lives in the binary world of 1s and 0s. HEX , ASCII, and decimal are only useful for us humans to give us a frame of reference that we can wrap our minds around.

    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.
  • MathieuMathieu Posts: 25
    The best way

    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!
  • yuriyuri Posts: 861
    Joe Hebert wrote: »
    You?re choosing to view it that way by setting the preference in Docklight to view incoming data as ASCII. Netlinx Studio or the Netlinx comm port have nothing to do with 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'
  • Joe HebertJoe Hebert Posts: 2,159
    yuri wrote: »
    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'
    Correct?
    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.
    GSLogic wrote:
    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.
    GSLogic wrote:
    My command string has a $00 in the string. From what I understand, it is removing the $00 completely.
    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
  • DarksideDarkside Posts: 345
    Joe Hebert wrote: »
    HEX is merely a figment of our imagination. The box doesn?t send HEX. A comm port (any comm port including Netlinx) sends binary bit streams of logic highs and logic lows. A comm port doesn?t know about and doesn?t care about HEX, ASCII, or decimal, as it?s simply irrelevant since it lives in the binary world of 1s and 0s. HEX , ASCII, and decimal are only useful for us humans to give us a frame of reference that we can wrap our minds around.

    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.
    Totally agree Joe, explanation of 1's and 0's et al.

    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.
  • filpeefilpee Posts: 64
    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.

    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.
  • DarksideDarkside Posts: 345
    filpee wrote: »
    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.
    I have acknowledged Joe's post - but it is NSX that is messing this up, not the projector, and that is what I am on about.

    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.
    Other programs I use give an option to view incoming data as either Ascii, Hex, Decimal, Ascii/Hex mixed and so on.
    That's exactly what I am saying NSX should do. Mixing display methods simply shouldn't happen.

    :-)
  • NEC Soulution
    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

    Try the 'CHARDM' command on the port. I've had success with 20 millisecs.
Sign In or Register to comment.