RS485-Verbindung wie bei NXC?
Author |
Message |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
 RS485-Verbindung wie bei NXC?
Hallo!
Ob es möglich sein wird, eine schnelle RS485-Verbindung wie bei NXC zu nutzen?
 |  |  |  | Code: // Lego NXT RS485 demo Master // modified from John Hansen nxcsamples // http://bricxcc.sourceforge.net/nbc/nxcsamples/485.zip
void SendRS485Bool(const bool value) { byte msg[]; ArrayBuild(msg, value, 0); SetHSOutputBuffer(0, 2, msg); SetHSOutputBufferOutPtr(0); SetHSOutputBufferInPtr(2); SetHSState(HS_SEND_DATA); SetHSFlags(HS_UPDATE); //send it }
void SendRS485Number(const int value) { string msg = Flatten(value); SetHSOutputBuffer(0, 5, msg); SetHSOutputBufferOutPtr(0); SetHSOutputBufferInPtr(5); SetHSState(HS_SEND_DATA); SetHSFlags(HS_UPDATE); //send it }
void SendRS485String(const string msg) { byte mlen = ArrayLen(msg); SetHSOutputBuffer(0, mlen, msg); SetHSOutputBufferOutPtr(0); SetHSOutputBufferInPtr(mlen); SetHSState(HS_SEND_DATA); SetHSFlags(HS_UPDATE); //send it }
void WaitForMessageToBeSent() { while(HSOutputBufferOutPtr() < HSOutputBufferInPtr()) Wait(1); }
task main() { // set port 4 to RS485 type SetSensorType(IN_4, SENSOR_TYPE_HIGHSPEED); SetHSState(HS_INITIALISE); SetHSFlags(HS_UPDATE); // set ports 1 and 2 to touch sensor type SetSensor(S1, SENSOR_TOUCH); SetSensor(S2, SENSOR_TOUCH);
byte mlen; // message length string buffer; // message buffer string SlaveMsgNum; // incoming message number int SlaveMsgLen; // incoming message length string SlaveNum; // out going message number string msg; // out going message string SlaveMsg; // message text int TimeOut; int x; int PollCount; int PollTotal; // total number of slave to poll bool ReadMsg; int ar_Polling[3]; // declare an array
// set array of slave numbers // each slave NXT must be in this list ar_Polling[0] = 2; ar_Polling[1] = 5;
PollTotal = 1; // Total number of slaves - 1 PollCount = 0; Wait(10);
while (true) { // Poll one slave in ar_Polling on each pass SlaveNum = NumToStr(ar_Polling[PollCount]); SlaveMsg = "P"; // P = Polling msg = SlaveNum + "," + SlaveMsg;
// if touch sensor 1 pressed create message for slave number = 5 if(Sensor(S1) > 0 && ar_Polling[PollCount] == 5) { msg = "5,C"; } // if touch sensor 2 pressed create message for slave number = 2 if(Sensor(S2) > 0 && ar_Polling[PollCount] == 2) { msg = "2,C"; }
// display out going message TextOut(0, LCD_LINE1, msg, true);
ReadMsg = true; // Send message SendRS485String(msg); WaitForMessageToBeSent();
msg = ""; TimeOut = 100; // set time out if not response from slave
// start with empty input buffer SetHSInputBufferInPtr(0); SetHSInputBufferOutPtr(0); // wait for a message to arrive. mlen = 0; while (mlen == 0 && TimeOut > 0){ TimeOut = TimeOut-1; if(TimeOut == 0) { // no message ReadMsg = false; SlaveMsgNum = NumToStr(ar_Polling[PollCount]); SlaveMsg = "error"; } mlen = HSInputBufferInPtr(); } Wait(2); // wait to get the whole message mlen = HSInputBufferInPtr();
// get message if(ReadMsg == true) { GetHSInputBuffer(0, mlen, buffer); // clear the incoming buffer SetHSInputBufferInPtr(0); // display buffer message TextOut(0, LCD_LINE2, buffer);
// phrase message SlaveMsgLen = StrLen(buffer); x = 0; while(x < SlaveMsgLen){ if(SubStr(buffer, x, 1) == ",") { // look for comma SlaveMsgNum = SubStr(buffer, 0, x); SlaveMsg = SubStr(buffer, x+1, SlaveMsgLen); break; } x = x+1; }
// read message and act on it if(SubStr(SlaveMsg, 0, 1) == "R") { // look for R if(SubStr(SlaveMsg, 2, 1) == "2") { // if from slave 2 // Turn on Motor A OnRev(OUT_A, 75); // turn Motor port A in reverse } if(SubStr(SlaveMsg, 2, 1) == "5") { // if from slave 5 // Turn on Motor A OnFwd(OUT_A, 75); // turn Motor port A forward } } }
// display message TextOut(0, LCD_LINE3, SlaveMsgNum); TextOut(0, LCD_LINE5, SlaveMsg); PollCount = PollCount+1; if(PollCount > PollTotal) { PollCount = 0; } Wait(500); // time delay so humans can watch it
Coast(OUT_A); } }
|  |  |  |  |
und für den Slave:  |  |  |  | Code: // Lego NXT RS485 demo Slave // modified from John Hansen nxcsamples // http://bricxcc.sourceforge.net/nbc/nxcsamples/485.zip
void SendRS485String(const string msg) { byte mlen = ArrayLen(msg); SetHSOutputBuffer(0, mlen, msg); SetHSOutputBufferOutPtr(0); SetHSOutputBufferInPtr(mlen); SetHSState(HS_SEND_DATA); SetHSFlags(HS_UPDATE); //send it }
void WaitForMessageToBeSent() { while(HSOutputBufferOutPtr() < HSOutputBufferInPtr()) Wait(1); }
task main() { // set port 4 to RS485 type SetSensorType(IN_4, SENSOR_TYPE_HIGHSPEED); SetHSState(HS_INITIALISE); SetHSFlags(HS_UPDATE); // set ports 1 and 2 to touch sensor type SetSensor(S1, SENSOR_TOUCH); SetSensor(S2, SENSOR_TOUCH);
byte mlen; // message length string buffer; // message buffer string msg; // incoming message string SlaveMsgNum; // incoming message number string SlaveMsg; // incoming message text int SlaveMsgLen; // incoming message length int SlaveNum; // number of slave NXT string strSlaveNum; // string form of slave NXT number string SendMsg; // outgoing message int x; int result; // result of Open File byte handle; // handle for Open File string buf; // buf for Open File
// Get slave number // each slave NXT must have a different number // can be assigned to SlaveNum the compiled to each slave NXT //SlaveNum = 5; // or a txt file can be uploaded to each slave NXT with a // different number in it then result = OpenFileRead("SlaveNum.txt", handle, handle); ReadLnString(handle,buf); result = CloseFile(handle); SlaveNum = StrToNum(buf); strSlaveNum = NumToStr(SlaveNum);
// start with empty input buffer SetHSInputBufferInPtr(0); SetHSInputBufferOutPtr(0);
Wait(10); while (true) { // wait for a message to arrive. mlen = 0; while (mlen == 0) mlen = HSInputBufferInPtr();
Wait(2); // wait to get the whole message mlen = HSInputBufferInPtr();
// read it. GetHSInputBuffer(0, mlen, buffer); // clear the incoming buffer SetHSInputBufferInPtr(0);
// display buffer message TextOut(75, LCD_LINE1, strSlaveNum, true); TextOut(0, LCD_LINE1, buffer);
// get SlaveNum of message SlaveMsgLen = StrLen(buffer); x = 0; while(x < SlaveMsgLen){ if(SubStr(buffer, x, 1) == ",") { // look for comma SlaveMsgNum = SubStr(buffer, 0, x); SlaveMsg = SubStr(buffer, x+1, SlaveMsgLen); break; } x = x+1; }
// Check sensors SendMsg = ""; if(Sensor(S2) > 0) { // if touch sensor 2 is pressed SendMsg = "R-" + strSlaveNum + "-S2"; // create message to send to master }
// Message for Me if(StrToNum(SlaveMsgNum) == SlaveNum) { TextOut(0, LCD_LINE3, SlaveMsgNum); TextOut(0, LCD_LINE5, SlaveMsg); // phrase message if(SubStr(SlaveMsg, 0, 1) == "C") { // Turn on Motor A OnFwd(OUT_A, 75); // turn on port A }
// Respone to master polling message if(StrLen(SendMsg) == 0) { // if no return message SendMsg = "A-" + strSlaveNum; // A = acknowledge } // send return message to master msg = strSlaveNum + "," + SendMsg; Wait(10); SendRS485String(msg); WaitForMessageToBeSent(); } Wait(10); Coast(OUT_A); // turn off port A } }
|  |  |  |  |
|
Sun Mar 02, 2008 2:28 pm |
|
 |
Dick Swan
Creator
Joined: Fri Feb 09, 2007 9:21 am Posts: 616
|
What is your question?
|
Tue Mar 04, 2008 10:36 am |
|
 |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
Wie es möglich ist, diese schnelle RS485-Verbindung wie bei NXC auch in RobotC zu programmieren?
_________________ regards, HaWe aka Ford #define S sqrt(t+2*i*i)<2 #define F(a,b) for(a=0;a<b;++a) float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}
|
Tue Mar 04, 2008 10:43 am |
|
 |
vnguyen
Site Admin
Joined: Wed Jan 24, 2007 10:44 am Posts: 442 Location: Pittsburgh, PA
|
Babelfish translation:
How is it possible to program this fast RS485-Verbindung as with NXC also in RobotC?
_________________Vu Nguyen Software Training Development Team | WebmasterNeed more support? Email ROBOTC Support at support@robotc.net to put in a support ticket Robotc.net| Robomatter Store | Robotics Academy | CS2N
|
Tue Mar 04, 2008 11:18 am |
|
 |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
means: please translate the NXC program to RobotC
_________________ regards, HaWe aka Ford #define S sqrt(t+2*i*i)<2 #define F(a,b) for(a=0;a<b;++a) float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}
|
Tue Mar 04, 2008 4:24 pm |
|
 |
Dick Swan
Creator
Joined: Fri Feb 09, 2007 9:21 am Posts: 616
|
Different development systems are likely to have different feature capabilities at any one point in time. At present time, the RS-485 interface is not exposed to end users in ROBOTC.
ROBOTC has always, and continues to, have the best all-around feature set among the various text-language based programming solutions for the NXT.
1. It is the only solution to have a high-level language run-time debugger. [Don't be confused with the assembly language debugger available with NBC; last time I looked it did not function with the NXC high-level language].
2. It supports floating point variables.
3. It has the highest performance (i.e. fastest execution speed) by a factor of three to 100 over the other NXT programming solutions.
4. It has the richest suite of LCD drawing library.
5. It has the richest suite of library functions -- trigonmetry.
6. It is standard "C" language.
7. And many more.
The vast majority of end users work with a single NXT. This has influenced development priorities so that multi-NXT operation (like RS-485) have taken lower priority. Access to RS-485 messages is planned over the next few months.
|
Tue Mar 04, 2008 5:28 pm |
|
 |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
Actually RobotC is not standard C (embedded C, ANSI C), e.g. see
- I/O and file access to files stored on the NXT (stdin, stdout, putf, open, read, write, close files) is missing, so the NXT can not write data or read data that have former been measured
- RobotC functions are not able to return complex ore more-dimensional values such as structures (e.g. cartesic or polar coordinates)
- dynamic variables on the heap, and pointer management are missing (or could not be found because of bad documentation)
- I/O functions like printf() or fprintf() have limited, and not an unlimited number of parameters (in RobotC it is restricted to only 2 variable parameters), and beyond that
- ANSI C always supports access to all hardware features, not depending on the actual platform, such as serial communication ports.
Because of the poor number of ports a second or third NXT is urgently needed to extend the available ports e.g. 8-12 motor ports for a tetrapod or a hexapod.
I really appriciate that you have planned fast RS-485 for the next time. But I would appriciate even more if you granted a higher priority to this feature.
(translation from German supported by babelfish  )
_________________ regards, HaWe aka Ford #define S sqrt(t+2*i*i)<2 #define F(a,b) for(a=0;a<b;++a) float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}
Last edited by Ford Prefect on Thu Mar 06, 2008 5:27 am, edited 1 time in total.
|
Wed Mar 05, 2008 3:36 am |
|
 |
Dick Swan
Creator
Joined: Fri Feb 09, 2007 9:21 am Posts: 616
|
You're right. There are a few standard "C" features that are (currently) unsupported in ROBOTC. Feedback from users indicate that the vast majority of these will not be encourntered by the typical ROBOTC user.
Anyone who wants to write applications communicating between four NXTs (i.e. 12 motors) is not a typical user.
I think you'll find that the alternative programming languages for the NXT that claim to be "C" or "C-like" are not. Simply look at:
1. All the features you've mentioned.
2. The way doubly indexed arrays are (not) handled.
3. How "call by reference" parameters are handled (i.e. copy to local variable on function entry and then copy back to calling parameter on function exit).
4. The lack of "typedef" and "enum" statements.
5. Etc.
RS-485 communications is coming on ROBOTC.
|
Wed Mar 05, 2008 8:42 am |
|
 |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
yes, you're right. None of the "C-like " languages actually got ALL of the features.
I purchased RobotC because it was advertized to have standard C features, above all floating point and transcendent functions. Although I'm missing dynamic variable allocation on the heap.
(BTW: I think, anyone who purchases RobotC because of floating point support etc. is somehow not a typical NXT user, but someone who has specific requests, so he is willing to pay for it).
Anyway, it was reason enough to BUY your language and not to try any other which was free of charge. Only it is hard to understand and to handle because the documentation is very poor and NOT AVAILABLE IN GERMAN. If you want to see a very good documentation with cross-reference, Key word search, hyperlinks and example codes please refer to the excellent one of Borland C++ - right from the beginning, already since they started with Turbo Pascal and Turbo C.
Anyway - from the start and for the beginning it's good work, and I really appriciate very much "that RS-485 communications is coming on ROBOTC".
Thanks, kind regards, and support Hillary!
_________________ regards, HaWe aka Ford #define S sqrt(t+2*i*i)<2 #define F(a,b) for(a=0;a<b;++a) float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}
Last edited by Ford Prefect on Thu Mar 06, 2008 5:24 am, edited 2 times in total.
|
Wed Mar 05, 2008 10:48 am |
|
 |
tfriez
Site Admin
Joined: Wed Jan 24, 2007 10:42 am Posts: 620
|
The type of help that you describe is currently being developed for ROBOTC... the ROBOTC for IFI is the current priority for this help documentation. You can review what the NXT version will look like in a month or two by looking at the IFI version here: http://www.robotc.net/ifi_webhelp/
As for translation of the products into different languages... this is not currently a high priority. I understand you purchase ROBOTC from a German distributor, but unless he was advertising the software as "German Localization", I don't see how you could expect everything to be in German nor the help documentation and a community support forum to be in German as well.
_________________Timothy Friez ROBOTC Developer - SW Engineer tfriez@robotc.net
|
Wed Mar 05, 2008 11:47 am |
|
 |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
sorry,
I just was used to get regular German support and help since it always has been granted from any software developer who sold his products in Germany, e.g. Ashton Tate, Microsoft, Borland, and even every single PC game producer.
I don't know (I'm no lawyer) but I think this is due to German trading laws.
regards
_________________ regards, HaWe aka Ford #define S sqrt(t+2*i*i)<2 #define F(a,b) for(a=0;a<b;++a) float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}
|
Wed Mar 05, 2008 12:01 pm |
|
 |
Shep
Novice
Joined: Fri Jan 18, 2008 11:07 pm Posts: 51 Location: Ohio
|
 I am a minority (I have 4 NXT)
I also wish that RobotC would support multiple NXT Bluetooth messaging.
I have built a very large robot system that takes up an entire 4'x8' piece of plywood. I have designed it to use 4 NXT, 2 RCX (via the HiTecnic IR sensor) as well as a few PF motors. I have been programming using NXT-G because it supports multiple NXTs as well as the HiTechnic sensors, but I have found that large programs make the NXT-G software unstable (no thanks to the $20 "upgrade"). I haven't achieved 25% of the programming necessary and I can't keep the software running efficiently. It really bogs down and I often have to use the three finger salute to exit the program.
RobotC has never given me those problems. It is like driving a Ferrari compared to a tricycle with one wheel missing.
I have seen many projects that use more than two NXTs. I think that you may be underestimating the number of people that want the superb functionality of RobotC along with the multiple NXT Bluetooth capability.
I have been building my robot for about two months and I am about ready to scrap it because it is worthless unless I can effectively communicate between the programmable bricks.
|
Fri Mar 14, 2008 10:56 pm |
|
 |
Dick Swan
Creator
Joined: Fri Feb 09, 2007 9:21 am Posts: 616
|
Multiple NXT support via Bluetooth is currently in development. Don't scrap your project! The infrastructure is all there for the support. It's a matter of a few days of development tweaks to make it work.
I think you may very well be disappointed in the performance delays with multiple BT slaves. What you should find with ROBOTC single slave messaging is that single mesasges are transmitted (in either direction) usually within 50 msec. Noise on the BT link can cause retransmission (for both ROBOTC and NXT-G) and stretch this to ~120 msec or even longer.
My measurements with NXT-G and single slave indicates that it takes at least 70 msec or longer to send a message from slave to master.
WHen you have multiple slaves the times go up dramatically. The master can have multiple slaves "connected" but only one is active at a time. It takes 100+ msec to switch the active slave. So if the master wants to send a message to three slaves you're probably talking about 400 msec for them to go through.
Similarly, if you have three slaves the following is the technique for messaging to the master. The slave does not send message autonomously. It cannot because it does not know whether it's connection is currently the master's "active" connection. nstead it buffers the message localls waiting for a poll request from the master. If the master is looking for a message it can possibly sequentially poll all three slaves to find one with a message which will take about 500 msec. I'm not sure about this; the interface may allow you to say "find message in queue 'N' but only look at slave 'M' rather than look at any slave".
Can your solution accept these kinds of delays?
I haven't seen anyone post anywhere on the Internet about the above kind of delays. They are not documented. My suspicion is that very few people are attempting multiple slaves on BT.
There is a "solution" to the above. It involves connecting all NXTs via the high-speed communications port (RS-485 on sensor port 4) and using its 1 Mb/s link instead of BT. You'd need to build a custom cable to make the connection. And it requires some ROBOTC development to expose messaging on the RS-485 communication interface to user programs. Personally I think this is a more useful development rather than the multiple BT; what do you think?
|
Sat Mar 15, 2008 10:49 pm |
|
 |
Shep
Novice
Joined: Fri Jan 18, 2008 11:07 pm Posts: 51 Location: Ohio
|
Thanks for the reply, I was really sweating it.
I run into the exact same problems you describe using NXT-G, and they are not a problem at all. I find myself putting in 1 sec wait blocks all the time around BT send and receive blocks and I don't think twice about it. Having messages flying around between four bricks means that at some time, there are going to be delays in transmission.
Connecting the four NXTs with a cable won't work with this project. Each of the bricks are mobile, so tethering them together would lead to problems.
For my project, 400 msec is a lightning bolt. Speed of transmission is not at all a consideration, unless it gets up to the 3 to 10 second range, and even then I could adapt.
My project is four gantry cranes that operate on the same track. The travel space is about 3 ft by 5 ft. I have partitioned the main track up into about 12 sectors. It is possible that all four cranes travel through the same space. What I want to do is create a register on the master of where each robot is and where it wants to go. Before it can move into a sector, it has to request entry from the master and the master has to approve or deny based on the location of the other three robots.
Each robot will pick and place a 6 stud by 6 stud "pallet" at a location, which can take 10 to 20 seconds. Each robot will move 24 pallets with a mosaic on top to create a large 96 pallet mosaic. Needless to say, this is an ambitious project both mechanically and to program. I have the pick and place program and the mechanical stuff down nicely, but getting the master to communicate with the three slaves has been a major obstacle. Processing the requests as well as the X-Y-Z movements in NXT-G is just far too much for the software to handle. I have switches and loops nested four deep, and the software really doesn't like it. I have spent about 40 hours just working on the communications and request processing, making it as efficient as possible, but it often locks up NXT-G.
Slow communications (which I don't think is slow at all for my project) is far, far better than no communications. It is a limitation of the NXT brick, not of the software. I am sending one request and one reply every 10 seconds or more. The 10 to 20 second window that I have to pick and place means that I could request the next movement long before the sector is actually needed to be open. All three slave requests could be processed in under two seconds if the requests came in that fast.
I hope this helps you understand why I really hope you get something worked out!
Shep
|
Sun Mar 16, 2008 4:17 pm |
|
 |
Shep
Novice
Joined: Fri Jan 18, 2008 11:07 pm Posts: 51 Location: Ohio
|
Dick,
Do you know when you expect to put out a version, or at least some information when we might see some multiple NXT support for RobotC? Weeks, Months, Years?
I have some time before I really need it, but if it is going to be a long period, I am going to move on to another project (reluctantly). There is no point leaving all this stuff built when I could be working on something else.
Shep
|
Mon Mar 17, 2008 9:41 pm |
|
|
Who is online |
Users browsing this forum: No registered users and 2 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|