View unanswered posts | View active topics It is currently Thu Sep 18, 2014 6:47 am






Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
RS485-Verbindung wie bei NXC? 
Author Message
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 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
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
What is your question?


Tue Mar 04, 2008 10:36 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
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
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:44 am
Posts: 439
Location: Pittsburgh, PA
Post 
Ford Prefect wrote:
Wie es möglich ist, diese schnelle RS485-Verbindung wie bei NXC auch in RobotC zu programmieren?


Babelfish translation:

How is it possible to program this fast RS485-Verbindung as with NXC also in RobotC?

_________________
Vu Nguyen
Software Training Development Team | Webmaster
Need more support? Use the ROBOTC Ticketing system

Robotc.net| Robomatter Store | Robotics Academy | CS2N


Tue Mar 04, 2008 11:18 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
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
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
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
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
Dick Swan wrote:
It is standard "C" language (...) Access to RS-485 messages is planned over the next few months.

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
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
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
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
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
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 602
Post 
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
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
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
Profile
Novice

Joined: Fri Jan 18, 2008 11:07 pm
Posts: 51
Location: Ohio
Post 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
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
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
Profile
Novice

Joined: Fri Jan 18, 2008 11:07 pm
Posts: 51
Location: Ohio
Post 
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
Profile
Novice

Joined: Fri Jan 18, 2008 11:07 pm
Posts: 51
Location: Ohio
Post 
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
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 16 posts ]  Go to page 1, 2  Next

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

Search for:
Jump to:  
cron



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.