and the SSC-32 will get the information of #0P%d without any problems.
But now I must use simulink, and the way I am doing it is by sending the command above from a function block to a serial send block wich sends the input to the com port selected. But this is not working since spintf and fprintf are not recognized in simulink and the data that needs to be send needs to be in ASCII code :S, how can I do it?
Yes, I know that the ATMEGA understands hexadecimal numbers etc, when I use Simulink the undefined integers uint16(x) (16bit) where x is a value between 2250-1500, and this will give a number that is stored in variable x, so far so good, but How can I send the information of #0P1500 instead of x? When I did unit16(’#0P1500’) it just gave the decimal value of each character such as u =
35 48 80 49 53 48 48
which is basically the decimal value of the # 0 P 1 5 0 0 in ASCII code. How can I inverse this situation where I can give hexadecimal or decimal value of the characters I want and the SSC 32 will read 35 as # for example.
I tried to find some documentations in Mathworks forums and help but neither gave me any solutions to my problem. When you meant Documentation were you referring to the Lynxmotion forums?
Simulink must have some documentation somewhere on the net concerning sending serial data. You simply send the ascii characters, there is no conversion. I think you are using the wrong command to send the data.
I have no experience with Matlab or Simulink. What I’m trying to say is there must be a method of defining what sort of data you are sending to the serial port. There should be a way to say this data is to be sent as ascii.
ic, what I found out is that the serial send block from simulink can only send binary data and the only variable parameters that it holds are: Valid data types are: single, double, int8, uint8, int16, uin16, int32, and uint32.
Normally in C or C++ to define a character you do the following
char a = 0x01
and when you declare a , a symbol will be displayed with hexadecimal value of 0x01, i,e binary 00000001B.
I can’t even imagine that there is no way to apply this by using simulink
Lets see if any programming guys chime in here. I’m no help.
I did spend my lunch hour searching google for help with simulink and the SSC-32. I found a place that will sell you an article abut serial data from simulink to the SSC-32. Didn’t want to drop $19.00 on it though. Good luck with it.
I suspect the bottom is your post. Two things, one is what is being sent is the decimal representation of the characters (which may not be an issue), and no carrage return is at the end of the string per the ssc-32 requirements (covered in the user’s manual). Try adding a “13” to the end of the strings you are sending.
Note that the “13” is the decimal repersentation of the carrage return. What is sent should look like 35 48 80 49 53 48 48 13
You might try something like below to get the carrage return in the string. Also the FWRITE and FREAD might be important.
temporary=sprintf(’#0P%d\r’,x)
Subject:
How can I write binary data to my serial port in MATLAB?
Problem Description:
I tried to use FPRINTF and DEC2BIN, but that did not work. I would like to be able to write binary data to my serial port in MATLAB.
Solution:
You should use FWRITE and FREAD to send and receive binary data via a serial port. You can view the help for these functions in the documentation.
Yes I am the author of that post from mathworks, I tried to apply the carrage return but it didn’t work either. I also tried the fread and fwrite but still behaved as as sprint and fprint.
Doesn’t the SSC 32 recolonize the binary or hex value that is sent to it? I mean if I send a decimal value of 35 the serial port will convert it to hex ( binary) of 23, now souldn’t the SSC 32 convert that 23 into an ASCII character of # ??
Binary is binary. decimal 35 = hex 23, and that value can also be interpreted as a ‘?’, if that’s what the code is looking for. The SSC-32 can be said to be “looking” for ASCII strings, but all it really wants is a stream of bytes with the proper values. an ‘A’ is 45H. Whether you create strings, or send arrays of bytes, the results can be the same.
Post a link to a SIMULINK language definition manual, and maybe one of us “programmers” can point you in the right direction, even if we don’t know SIMULINK.
(They all borrow from C anyway, which borrowed from FORTRAN)
Hi KM6VV, simulink is an object oriented program where it holds function blocks interconnected with each other to create a whole program. Each block represents a function process such as display value, generate a sine way, plot the sign wave etc. So in other words it does not involve almost any programming. But Simulink does not allow the transfer of strings and characters from one block to another, and this is the problem. It uses basic C++ and C# language (MATLAB).
Regards the ASCII strings, Simulink or any other language will send any character or string by either hex or binary (hex is converted into binary code, the language of processors anyways). So I guess the SSC is recieving serial binary numbers, and then converts them into ASCII characters. well at least thats what I think. So my problem that I can’t understand is why doesn’t SSC recognize a hex number which represents the particular character or a number ?
You are at least partially correct. The SSC32 simply wants a stream (list, string etc.) of bytes. Each byte can be viewed as a decimal, hex, ASCII or even a graphic value! The manual for the SSC-32 lists command strings in an ASCII representation. So for each byte sent, you need to make up the same binary pattern for that byte. i.e., “A51” (something I can do in my head) would be the three bytes 45H, 35H and 31H. Three bytes from three ASCII characters. Most languages allow you to use other base notations, or ASCII to define a value.
Well, pretty much everything with computers and chips is done in binary. Serial communications are done in binary. The hex and decimal stuff is just how the particular programming language is made to see and represent binary. The simulink appears to like decimal repersentation. In the below I suspect the ’ ’ around the string tells simulink what in side is ascii. The 13 is probably seen as a decimal representation of a byte, which in this case is a carrage return (or 0001101 in binary). Without any simulink programming info, one would just have to use trial and error. I suggest you get Portmon (free) to see just what is being sent to the serial port (use the hex view so hidden characters are visible. Try the below and see if the servo moves. Note that the S is probably case sensitive to what you used.
