Shop OBEX P1 Docs P2 Docs Learn Events
Issue interfacing the Parallax Servo Controller - USB — Parallax Forums

Issue interfacing the Parallax Servo Controller - USB

DutchDakDutchDak Posts: 11
edited 2006-10-23 14:05 in Robotics
I am writing an interface for the USB Parallax Servo Controller in C# (Microsoft 2005 Express). I have a working set-up now.

However:

If I send a command e.g. !SCVER? the result in the buffer is not 3 bytes as listed in the documentation, but 11 bytes. That is 8 bytes for the (repeated) command including $0D and 3 bytes for the result.

For the "set position" command 8 bytes are returned instead of "none" as stated in the documentation.

Question:

Is there a way to disable the echo of the command by the PSC ?
Or is this an error in the documentation ?

Herman.

Comments

  • John R.John R. Posts: 1,376
    edited 2006-10-16 21:44
    It's been a while since I use the MS Serial/USB connection stuff, but I'm assuming that you're connecting via a "serial port".

    Is it possible that you have the "echo" turned on as part of the serial connection. (i.e. You're getting the "local" echo from the send because of the settings on the port or stream object you're using.)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    John R.

    8 + 8 = 10
  • DutchDakDutchDak Posts: 11
    edited 2006-10-16 21:55
    Yes, I have been thinking about / looking at the "echo" feature.

    But as far as I discovered, the "echo" is a feature of the "serial device recieving" and not the device that is sending. I could not find any clues in the SerialPort class documentation...

    So now my assumption is that the PSC USB should get a command to turn off "echo", or that the PSC USB is programmed to give an echo. In both cases the documentation needs an update.

    Herman.
  • allanlane5allanlane5 Posts: 3,815
    edited 2006-10-16 22:22
    While the DEVICE may also 'echo', it is possible to set up the serial port so the serial port hardware (in this case, the USB hardware acting like a serial port) echoes from itself. This is good for 'half-duplex' devices which provide no echo, so in hyperterm you can see what you are typing.

    It sounds like you have this 'half-duplex' echo turned on in C#.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-10-16 22:44
    Hello,
    ·
    ·· I am in the process of confirming this, but I believe due to the nature of the main serial interface (being a single I/O pin) that data is always going to be echoed back as it is sent.· Your C# program must filter what it sends from the responses.· Hence the ‘set position’ command isn’t really returning a response, but rather you’re seeing echo from the serial I/O pin.· I hope this helps.· Take care.


    EDIT: Confirmed, since there is a single I/O pin anything sent is connected to, and therefore sent back to the PC.· This doesn't affect the BASIC Stamps since they have no FIFO buffer.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support


    Post Edited (Chris Savage (Parallax)) : 10/16/2006 10:55:15 PM GMT
  • John R.John R. Posts: 1,376
    edited 2006-10-17 13:57
    Chris;

    This should probably be an "addendum" to the docs, especially as the USP version of the PSC seems targeted at a PC interface application.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    John R.

    8 + 8 = 10
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-10-17 15:12
    John,
    ·
    ·· I will pass this information along.· As a note, while the USB-PSC does have a USB Port, it isn’t specifically targeted at PC use.· It is essentially a serial version with the USB Port added and can work in place of the serial version on a BASIC Stamp just fine.· It is the nature of the single I/O pin interface that causes the echo.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • John R.John R. Posts: 1,376
    edited 2006-10-17 16:07
    Chris;

    I didn't realize the serial port was still available. I guess I didn't look at the specs very well. I now see the reference to connecting the BOE or other device. What "threw me" was that the connections weren't labeled on the board diagram in the user manual. My bad for not looking closer.

    I'll have to keep this in mind...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    John R.

    8 + 8 = 10
  • DutchDakDutchDak Posts: 11
    edited 2006-10-17 18:42
    Chris (and others),

    Thanks for your help. I can go ahead now smile.gif

    My sugestion is to update the manual of the PSC-USB (it is a great product).
    Additionally the actual documentation of the PSC-USB does not refer to the programming options.
    This is only mentioned at the page on the site where a reference is included to the documentation of the PSC-serial for programming.
    Combining the documentation to 1 will to my opinion make the PSC-USB product more accessible.

    When I finish testing in the next weeks I post the C# interface (as is) in the "Completed projects" forum. Since it is .NET it can also be used for VB etc.

    Herman.
  • kwokkiekwokkie Posts: 8
    edited 2006-10-18 09:39
    Hi!
    I am also using the parallax servocontroller 28823 (USB). In my program, I basically wait until all 8 characters are echoed back before
    continueing, but I found that from time to time, not all characters are echoed back, and my program gets stuck waiting for the 8th
    character. Also, the !SCVER? command seems to be interpreted as a move command to servo channel 0 occasionally.
    My (c++) program runs on an armadillo-9 processorboard (www.atmark-techno.com/en/products/armadillo/a9).
    Linux kernel 2.4.27-a9-1 with support for the FTDI-chip is installed on the armadillo-9, and I'm using
    libSerial to talk to the servo controller.

    Any help is much appreciated.

    thanks,

    Kwokkie
  • kwokkiekwokkie Posts: 8
    edited 2006-10-18 09:54
    some comments on the documentation;
    I have found a version v2.3 of the PSC 28023 documentation on this website :www.zerko.ch/parallaxshop/motorservo/50150395c006d2559.php.
    While the version on www.parallax.com is v2.2. Is the documentation on zerko.ch an unofficial one? (The only difference that I spotted is that in
    v2.3 is mentioned that the serial port settings are 8 bits, no parity, 2 stopbits.)

    also, the documentation states that the reply of the !SCRSPx command is x y z, where x is the channel, and z:y is the value reported.
    This was a bit confusing to me, as I interpreted z:y as z being the most significant byte, and y being the least significant.
    I'm fairly certain that it's the other way around (z is low byte).

    kind regards,

    Kwokkie
  • DutchDakDutchDak Posts: 11
    edited 2006-10-18 19:19
    Kwokkie,

    What I do is to clear the buffer before I issue the commands where a result is read: !SCVER?, !SCSBR... and !SCRSP.
    I have (till now) no problem reading the results.

    For the "move" command I empty the buffer after the instruction to prevent buffer overflow.

    Note that for comands where you read a result, your need to give the PSC USB some time to process.
    If you read too quickly you will not recieve all the output characters (e.g. only the first 2 out of 3 of the version number).
    For the commands !SCVER?, !SCSBR... and !SCRSP I use a delay of 0.4 seconds.
    For the application I build this waiting time is not an isue.

    I hope this helps.

    (It would be nice if the manual was more specific about this ...)

    Herman.

    PS: the z:y specs in the docs are correct ...
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-10-18 21:26
    Gentlemen,
    ·
    ·· We are looking into revising the manuals.· Thanks for your continued input.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • edwin220480edwin220480 Posts: 1
    edited 2006-10-19 00:56
    hi everyone! can anyone help me, im having trouble working with the hexcrawler robot ive already finish the program in the manual but it is not working although there is a small reaction in the motor when turning it on but it wont move after that, ive also loosen all the screw still not working. pls help?
  • kwokkiekwokkie Posts: 8
    edited 2006-10-19 12:32
    Thanks for your help DutchDak,

    I'm not sure I understand your comment about reading too quickly though. If I read my input buffer too early, it should simply be empty until the characters actually arrive. I'm not sure I can miss incoming characters by reading my input buffer too early. confused.gif
    I use a timeout of 4 seconds to wait for the characters to echo back, but still get a timeout occasionally (if I run my program for an hour or so).

    I'll go study the libSerial library some more, maybe my understanding of libSerial is off.

    thanks,

    Kwokkie
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-10-19 13:13
    Kwokkie -

    This is just a mere passing comment relative to your question:

    You asked:

    "I'm not sure I can miss incoming characters by reading my input buffer too early."

    I am NO EXPERT on the PSC, however, it _may_ be necessaey for one to pause or wait before accessing any given input/output device to permit it to operate within in its operational parameters.

    Regards,

    Bruce Bates

    Post Edited (Bruce Bates) : 10/19/2006 1:17:14 PM GMT
  • kwokkiekwokkie Posts: 8
    edited 2006-10-19 13:29
    DutchDak said...

    PS: the z:y specs in the docs are correct ...

    That is really odd. When I reset the servo controller, all control signals are set to 750, and if I issue a !SCRSPx command, the only way I get the number 750 back is when I treat the 2nd character (y) as high byte and 3rd character(z) as low byte.
  • kwokkiekwokkie Posts: 8
    edited 2006-10-19 13:41
    Bruce Bates said...
    Kwokkie -

    This is just a mere passing comment relative to your question:

    You asked:

    "I'm not sure I can miss incoming characters by reading my input buffer too early."

    I am NO EXPERT on the PSC, however, it _may_ be necessaey for one to pause or wait before accessing any given input/output device to permit it to operate within in its operational parameters.

    Regards,

    Bruce Bates

    Well, I'm using the libSerial to receive incoming characters. If I understand the library correctly, the library handles incoming signals or interrupts from the serial port, and pushes the data in the input buffer, if there is any, on a seperate queue for me to read. Basically, I just wait until this queue reaches a certain size (8 characters in my case) before flushing the queue and continueing, with a timeout of 4 seconds. I am assuming that 4 seconds is more than enough time for the PSC to send me the characters. You do have a point that the way the OS accesses the PSC might cause trouble, though. I hope not, because I have little control over that sad.gif

    thanks for your explanation,

    Kwok
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2006-10-19 14:16
    Kwokkie,
    I can confirm that z is the lowbyte and y the highbyte.
    Sometime ago I wrote a java class and encountered this
    documentation error also.
    For your convenience I have attached that java class.
    It also has info in it, regarding networked board and
    how to handle replies.

    regards peter
    PS. You can open the file with notepad.
    java
    java
    psc.java
    12K
  • DutchDakDutchDak Posts: 11
    edited 2006-10-19 21:18
    Peter Verkaik said...
    Kwokkie,
    I can confirm that z is the lowbyte and y the highbyte.
    Sometime ago I wrote a java class and encountered this
    documentation error also.
    For your convenience I have attached that java class.
    It also has info in it, regarding networked board and
    how to handle replies.

    regards peter
    PS. You can open the file with notepad.
    Well I am a bit lost with "high" and "low", but below my code for getting the position.
    I only get correct results if I swap the results in PSCBuffer.
    Herman.

    public UInt16 GetServoPosition(byte Channel)

    {

    byte[noparse]/noparse Token = new byte[noparse][[/noparse]8];

    byte[noparse]/noparse PSCBuffer = new byte[noparse][[/noparse]11];

    // The buffer may not be empty, so this is done explicitly

    Com.DiscardInBuffer();

    //································01234567

    Token = Ascii.GetBytes("!SCRSPc\x0D");

    // Syntax: !SCRSP x $0D (no spaces)

    //············ x = servo channel, binary number 1 - 31 (16 - 31 on second board)

    // Reply: x y z (no spaces / 3 bytes)

    //·········· z:y = 2 bytes (uint16) for position

    Token[noparse][[/noparse]6] = Channel;

    PSCWrite(Token);

    // wait 0.4 seconds to give the PSC the chance to respond

    Pause(0.4);

    // returns the command (8 positions) and x y z (3 positions)

    Com.Read(PSCBuffer, 0, 11);

    // High and Low byte have to be in different order for BitConverter.ToUInt16

    PSCBuffer[noparse][[/noparse]0] = PSCBuffer[noparse][[/noparse]10];

    PSCBuffer[noparse][[/noparse]1] = PSCBuffer[noparse][[/noparse]9];

    // return only the position

    return (UInt16) (BitConverter.ToUInt16(PSCBuffer, 0) - ServoStart);

    }

  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2006-10-19 21:30
    // High and Low byte have to be in different order for BitConverter.ToUInt16

    PSCBuffer[noparse][[/noparse]0] = PSCBuffer[noparse][[/noparse]10];

    PSCBuffer[noparse][[/noparse]1] = PSCBuffer[noparse][[/noparse]9];

    // return only the position

    return (UInt16) (BitConverter.ToUInt16(PSCBuffer, 0) - ServoStart);

    }

    You put z in [noparse][[/noparse]0] and y in [noparse][[/noparse]1],
    and since [noparse][[/noparse]0] is the lowbyte, z:y in the doc should by y:z
    (it is normal practice to name highbyte first in case of 16bit value)

    regards peter
  • kwokkiekwokkie Posts: 8
    edited 2006-10-20 06:50
    DutchDak,

    on x86 architecture CPU's, multibyte numbers are stored in Little Endian order, meaning that the least significant bytes are stored in the lower memory adresses.
    When converting the first two bytes of PSCBuffer to a 16bit integer, PSCBuffer[noparse][[/noparse]0] will be treated as low byte, and PSCBuffer as high byte. If you would compile
    your code for a Motorola processor, for example, it would be the other way around.


    Peter,

    thank you for your source code. Is the source for the Uart class that you use available too?

    regards,
    Kwok
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2006-10-20 07:19
    Kwokkie,

    This psc code and more is available at the yahoo group
    http://tech.groups.yahoo.com/group/JavelinCode/

    The Uart class is located here:
    http://tech.groups.yahoo.com/group/JavelinCode/files/Javelin%20Stamp%20IDE/lib/stamp/core/
    but I attached it also for you.

    regards peter
    java
    java
    Uart.java
    28K
  • kwokkiekwokkie Posts: 8
    edited 2006-10-23 14:05
    I think I have found the cause of my problems. Apparently, writing to STDIO interferes with I/O over the serial port. Some characters sent to the serial port get lost if STDOUT hasn't finished printing to the screen. Waiting a couple of millieseconds after writing to STOUT before writing commands to the PSC seems to work fine, so I guess it was a problem with the armadillo-9 bord.

    anyway, thanks everyone for your help!

    --Kwokkie

    Post Edited (kwokkie) : 10/23/2006 4:15:11 PM GMT
Sign In or Register to comment.