Reading Tic alt_dev_nr with NodeMCU

hi,
i’m trying to read the Tic’s (834) alt_dev_nr:
with an I2C connection from a NodeMCU this works.
from an Arduino with a serial connection it also works.

through a serial connection from a NodeMCU it doesn’t.
the value i get is 255.
(sending commands to the Tic works spotless).

what could be the reason?

thanks for any hint.

rolf meesters

Hello, rolfmeesters.

Can you post more details about what you are trying in your NodeMCU setup with serial communication? For example, what is the alternative device number on the Tic set to, and could you post the code your are using to read it?

Brandon

BrandonM via Pololu Forum schreef op 03-03-2021 22:05:

blocked.gif | BrandonM Pololu Employee
March 3 |

  • | - |

Hello, rolfmeesters.

Can you post more details about what you are trying in your NodeMCU setup with serial communication? For example, what is the alternative device number on the Tic set to, and could you post the code your are using to read it?

Brandon


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

hi Brandon,

i’m doing SerialPositionControl on a number of steppers, wireless with NodeMCU’s.

reading the alternative Tic number makes it possible to use 1 sketch for all Node’s.

with I2C it has worked.

with Serial until now not.

attached is the test/demonstration sketch used for Arduino and NodeMCU.

/*
* test to read the alt_dev_nr from a Tic with serial connection
* with Arduino Uno Wifi Rev2 or NodeMCU 1.0 (ESP-12E module)
* the Tic used is set to alternative number 15
*/
#define this_sketch "test_Ticnr"
#include <ESP8266WiFi.h>
#include <Wire.h>
#include <Tic.h>

//uncomment next line for Arduino
#define Node
#ifdef Node
#define ticSerial Serial
#define meld Serial1
#else
#define ticSerial Serial1
#define meld Serial
#endif

//uncomment next line for single Tic
#define array

#ifdef array
TicSerial tic[] = {
TicSerial(ticSerial, 14),
TicSerial(ticSerial, 15),
TicSerial(ticSerial, 16),
TicSerial(ticSerial, 17),
TicSerial(ticSerial, 18),
TicSerial(ticSerial, 19),
TicSerial(ticSerial, 20),
TicSerial(ticSerial, 21),
TicSerial(ticSerial, 22),
TicSerial(ticSerial, 23),
TicSerial(ticSerial, 24),
TicSerial(ticSerial, 25),
TicSerial(ticSerial, 26),
};
#else
TicSerial tic(ticSerial);
#endif

void get_tic_number(){
uint8_t alt_offset = 0x6A;
uint8_t alt_length = 1;
uint8_t alt_dev_nr;
#ifdef array
tic[0].getSetting( alt_offset, alt_length, &alt_dev_nr);
#else
tic.getSetting( alt_offset, alt_length, &alt_dev_nr);
#endif
meld.println(alt_dev_nr);
meld.println((alt_dev_nr & 127) - 14);
}

void setup() {
ticSerial.begin(57600);
#ifdef Node
ticSerial.swap();
delay(2000);
#endif
// tic[0].exitSafeStart();//does not make a difference
delay(20);
meld.begin(57600);
meld.println(this_sketch);
get_tic_number();

}

void loop() {}

test_Ticnr.ino (1.51 KB)

Right now, your code is sending Pololu Protocol commands with a device number of 14 (the default). So, any Tics you have connected with a device number or alternative device number of 14 will try to respond to that command at the same time. If there is more than one, they will interfere with each other. Can you list all of the Tics that are currently connected to your NodeMCU with each of their device numbers and alternative device numbers specified?

Also, could you elaborate on how you are using the alternative device number?

Brandon

BrandonM via Pololu Forum schreef op 04-03-2021 22:23:

blocked.gif | BrandonM Pololu Employee
March 4 |

  • | - |

Right now, your code is sending Pololu Protocol commands with a device number of 14 (the default). So, any Tics you have connected with a device number or alternative device number of 14 will try to respond to that command at the same time. If there is more than one, they will interfere with each other. Can you list all of the Tics that are currently connected to your NodeMCU with each of their device numbers and alternative device numbers specified?

Also, could you elaborate on how you are using the alternative device number?

Brandon


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

each Tic has number 14 as a general number and an alternative number (15 - 26).

each Tic has its own NodeMCU.

this is also how i used the test sketch.

in our installation the Node’s receive the same list of commands, each Node uses the alternative number to select the right one out of the list.

as i said before, with an I2C connection between Node and Tic this works.

rolf

installation.mp4 (2.01 MB)

Could you try running this for getting the alternative device number and posting the output that it prints?

void get_tic_number() {
  uint8_t alt_dev_nr = 100;
  tic[0].getSetting(0x6A, 1, &alt_dev_nr);
  if (tic[0].getLastError()) {
    meld.print("Error ");
    meld.println(tic[0].getLastError());
  }
  else {
    meld.print("Number ");
    meld.println(alt_dev_nr);
  }
}

Additionally, can you post a copy of the settings file for the Tic you are testing with that is producing the problem? You can save the settings file from the “File” drop-down menu of the Tic Control Center while the Tic is connected.

Brandon

BrandonM via Pololu Forum schreef op 06-03-2021 0:17:

blocked.gif | BrandonM Pololu Employee
March 5 |

  • | - |

Could you try running this for getting the alternative device number and posting the output that it prints?

void get_tic_number() {
  uint8_t alt_dev_nr = 100;
  tic[0].getSetting(0x6A, 1, &alt_dev_nr);
  if (tic[0].getLastError()) {
    meld.print("Error ");
    meld.println(tic[0].getLastError());
  }
  else {
    meld.print("Number ");
    meld.println(alt_dev_nr);
  }
}

Additionally, can you post a copy of the settings file for the Tic you are testing with that is producing the problem? You can save the settings file from the “File” drop-down menu of the Tic Control Center while the Tic is connected.

Brandon


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

output:

test_Ticnr
Number 255

settings file attached

rolf

tic_settings.txt (1.27 KB)

by accident i did run the test without the connection between the Node and the Tic:
the output was the same.
so, it looks like the problem is with the Rx line of the Node.

rolf

You might try removing the Tic as a variable and doing a loop-back test with your NodeMCU (i.e. connecting its TX pin back to the RX pin to see if you can read back the data cleanly). If that works as expected, then it might be a problem with your connections, so you can do a continuity test to make sure the connection from the TX pin on the Tic is getting all the way to the RX pin on your NodeMCU and also that there is a good common ground connection between the two devices.

Brandon

BrandonM via Pololu Forum schreef op 09-03-2021 1:15:

blocked.gif | BrandonM Pololu Employee
March 9 |

  • | - |

You might try removing the Tic as a variable and doing a loop-back test with your NodeMCU (i.e. connecting its TX pin back to the RX pin to see if you can read back the data cleanly). If that works as expected, then it might be a problem with your connections, so you can do a continuity test to make sure the connection from the TX pin on the Tic is getting all the way to the RX pin on your NodeMCU and also that there is a good common ground connection between the two devices.

Brandon


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

thanks Brandon for the support.

probably the cause is the voltage difference between the Tic and the NodeMCU: 5V versus 3.3V.

for Node-Tx → Tic-Rx that’s apparently not a problem, but the other way around it is.

other commands like getMaxAccel and getMaxSpeed give results but not what it should be:

maxAccel 6400001 should be 25000, maxSpeed 2105032847 which should be 2500.0000.

strange detail: the last digits of maxSpeed change with the alt_dev_nr: 47 for nr 15, 51 for nr 19.

using a voltage divider on the Tic-Tx → Node-Rx line did nothing good.

getMaxAccel and getMaxSpeed both are giving 0 and the alt_dev_nr still gives 255.

i’m started working with a combination of I2C and Serial Tx only.

the ‘get alt_dev_nr’ is done with TicI2C, and then all position commands go with TicSerial (only Tx).

(i use on the Node Serial1).

the first tests with this setup go well.

i hope you’re not going to tell me that this solution will confuse the Tic sooner or later.

rolf

It’s strange that adding a voltage divider changed your readings; from information I could find with some quick Internet searches, it sounds like NodeMCU modules are generally 5V tolerant, but if you have any more specific information about yours not being 5V tolerant, then you should definitely be using something like a voltage divider or level shifter.

It should be fine to switch between using TTL serial and I2C commands on-the-fly if that is working for you. However, we noticed that there is a relationship between the values you mentioned for maxAccel: 6400001 is 0x61A801and 25000 is 0x61A8. So, your NodeMCU might have some junk left in its serial buffer that is messing up the readings. If you want to try the serial communication one more time, could you try replacing your setup() function with this and seeing if that makes any difference?

void setup() {
  ticSerial.begin(57600);
#ifdef Node
  ticSerial.swap();
  delay(2000);
#endif
  // tic[0].exitSafeStart();//does not make a difference
  delay(20);
  meld.begin(57600);
  meld.println(this_sketch);
  delay(1000);
  while (ticSerial.available()) { ticSerial.read(); }
  get_tic_number();
}

Brandon

BrandonM via Pololu Forum schreef op 10-03-2021 1:07:

blocked.gif | BrandonM Pololu Employee
March 9 |

  • | - |

It’s strange that adding a voltage divider changed your readings; from information I could find with some quick Internet searches, it sounds like NodeMCU modules are generally 5V tolerant, but if you have any more specific information about yours not being 5V tolerant, then you should definitely be using something like a voltage divider or level shifter.

It should be fine to switch between using TTL serial and I2C commands on-the-fly if that is working for you. However, we noticed that there is a relationship between the values you mentioned for maxAccel: 6400001 is 0x61A801and 25000 is 0x61A8. So, your NodeMCU might have some junk left in its serial buffer that is messing up the readings. If you want to try the serial communication one more time, could you try replacing your setup() function with this and seeing if that makes any difference?

void setup() {
  ticSerial.begin(57600);
#ifdef Node
  //ticSerial.swap();
  delay(2000);
#endif
  // tic[0].exitSafeStart();//does not make a difference
  delay(20);
  meld.begin(57600);
  meld.println(this_sketch);
  delay(1000);
  while (ticSerial.available()) { ticSerial.read(); }
  get_tic_number();
}

Brandon


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

YOU FOUND IT.

the numbers come out now like they should, alt_dev_nr, maxSpeed, maxAccel.

it’s really great that you are willing to spend the effort to help people like me out.

i wish i could do something in return.

rolf

1 Like

I am glad we could help get it working! Thank you for the kind words. You don’t have to do anything in return, but if you feel so inclined, you can use our donation page (from the early days of the pandemic, left up for people who generally want to continue supporting what we do):

You can also help us by leaving reviews on sites like Google and generally helping spread the word about us.

Good luck on your project!

Brandon