What is the maximum sustained data transmit rate for Ethernet on Teensy?

[clinker8]

For T4.1-based controllers, since I can't use USB Serial while they are running, I log to RAM and read the data via hardware serial (UART). The main technique that I use for production systems is to log continuously to a ring buffer and then stop the udpates when a fault occurs. After the system enters a "shutdown" state, I can then read the data via UART and examine what was happening before and after the fault.

For data acquisition systems, where I want to log large amounts of data, I write to SD during operation, then transition to a "file transfer" state where I can retrieve the files via MTP (USB). The SD approach is the one that better fits the way you are trying to debug. SdFat has a built-in RingBuf template class that makes it easy to log at high frequency as long as the total data rate stays within bounds. I've done some bench-marking that shows it's possible to log to SD continuoulsy at 1 MB/sec using less than 1% of the CPU, with no disabling of interrupts and never blocking more than about 5 us. That's pretty good, and I've never had a data rate near 1 MB/s in a working system. It's always much less than that. The diagram below shows the basic idea of writing to the RingBuf from the ISR and then writing the data to SD in loop(). There are two rules you must follow to avoid blocking in the calls to SD's write() function. (1) ALWAYS write to SD in chunks of 512 bytes, and (2) ONLY write to SD when file.isBusy() returns false. RingBuf must be large enough to allow compliance with these two rules, and my rule of thumb is the buffer needs to be large enough for 50 ms of data. For 1 MB/s data rate, that means you need a 50KB buffer.



The easiest change for you to make would be to write to UART instead of USB Serial, but instead of writing on every interrupt, write only when you detect a problem.

Thanks for the suggestions. Will try to make something workable from it. Obviously will require a lot more planning than my previous ad hoc methodology. I'll have to think long and hard about what the bounds are for data or state transitions being an error or not. Haven't thought about it that way. In my mind I was thinking states in a state machine, but now I have to bound the data values in each state, in order to test for out of bounds conditions.

May take me some time to plow through that, but I think it is worth it. My text mode logging was exceeding 1MB/sec and that was timestamp and state, and very little data, and that was not logging every interrupt, only the main loop. If I go to binary, I'll get at least 2:1 reduction, maybe a little more? That's still over FTDI rates. Hmm, may only be able to send out of bound data via FTDI, or log to SD card.

 

[MarkT]

My control algorithm is position dependent, not velocity dependent. Actions are taken to exactly maintain the relationship between the spindle angular position and the Z position of the carriage (and indirectly the stepper angle). If the lathe motor slows down due to load, or any other reason, the Z position exactly tracks. This is essential to guarantee that screw thread cuts are true, with no wavering or drunkenness in pitch.

How often do you think you need to sample position? Typically inertia will smooth out motion very effectively so that having to sample at a microsecond level isn't useful.

Many motor control systems for moderate position tend to run current-control loops around 10kHz, main control loop at 1kHz. For better performance perhaps 100kHz is sufficient.

Do you have nested/cacaded control loops?

 

[clinker8]

How often do you think you need to sample position? Typically inertia will smooth out motion very effectively so that having to sample at a microsecond level isn't useful.

Many motor control systems for moderate position tend to run current-control loops around 10kHz, main control loop at 1kHz. For better performance perhaps 100kHz is sufficient.

Do you have nested/cacaded control loops?

I'm sampling multiple things, angular position, aka the spindle, and linear position in Z. When the lead screw clutch is engaged the Z position has to follow exactly the spindle angular position. Yes, I'm taking advantage of the Z carriage inertia, and to some extent the spindle inertia. I'm not sampling at microsecond rates, but more like 35us (at 400 RPM of the spindle). That's about 27 KHz, if I recall correctly. The stepper has to run at an exact fraction of the spindle, or your machined thread is junk.

Sort of, but not really for the control loop. In one way yes, since I need to do a synchronization process, but after the sync, it's really just tracking the spindle and emitting a step at the right time.

 

[MarkT]

Ah, its a stepper - but with closed-loop feedback? Microstepping?

Should be straightforward to drive your loop(s) from a timer interrupt and read the encoder then. You might want to do a little smoothing on the encoder readings and interpolate between encoder increments. You can also extrapolate into the future from this smoothed encoder model.

 

[joepasquariello]

Ah, its a stepper - but with closed-loop feedback? Microstepping?

Should be straightforward to drive your loop(s) from a timer interrupt and read the encoder then. You might want to do a little smoothing on the encoder readings and interpolate between encoder increments. You can also extrapolate into the future from this smoothed encoder model.

@MarkT, I agree with you, but @clinker8 has done something different. Are you familiar with the Bresenham Line Algorithm? It's an algorithm first developed in the late 60s for choosing pixels to best represent a straight line on a display or plotter. Depending on the slope of the line and the resolution of the display, you might end up with several pixels on one row, then one on the next row, then several on the next row, etc. It has the advantage of requiring only simple logic and integer math, so it is used in a lot of different contexts. I think @clinker8 is using it to step the motor at a precise ratio (on average) to encoder pulses, where the ratio represents the pitch of the thread he is trying to cut. On each edge of the encoder, his logic decides whether or not to do a step of the motor to maintain the correct ratio. Pretty cool, actually. I'm going to be on the lookout for applications that involve ratios and discrete steps so that I can try it.

 

[clinker8]

Ah, its a stepper - but with closed-loop feedback? Microstepping?

Yes, and yes.

Should be straightforward to drive your loop(s) from a timer interrupt and read the encoder then.

Not really. I don't know the spindle RPM, it is computed from the encoder counts in a time interval, and the spindle RPM can depend on lathe motor load, or the whim of an operator. For all I know, the RPM is wowing, but my algorithm doesn't care. I certainly don't know the time exact enough just by the RPM, it would be close, but not machinist close. Machinist close is getting effective dimensional accuracy of less than 0.001". Actually that would be awful. I'm going for better than 0.0001". To date, I get my lathe to automatically stop within 0.0002" of the set point.

You might want to do a little smoothing on the encoder readings and interpolate between encoder increments. You can also extrapolate into the future from this smoothed encoder model.

I don't know how to make a machinist grade anticipator. Most extrapolations out to the future have errors (lag). They may correct, but unless they correct very quickly, it's not suitable. Fast closing extrapolators are hard to do.

The encoder position doesn't lie - it's ground truth. Well, that's if it's perfect, and nothing is, if you look closely enough. I've seen some very interesting behavior while I was logging my feed to stop. The micro-steps and steps are not uniform, but they do not accumulate error on my closed loop stepper. But if I try to do that kind of detailed high speed logging at higher speeds, I run out of CPU cycles and the Teensy crashes (chokes in USB) and resets.

 

[MarkT]

The encoder position is potentially out of date when you use it, and granular - interpolation can improve both of these - in effect converting the steppy output of the sensor to a smoother signal - less noise is then injected into the control loop (although the latency of the loop can't be improved, and might be slightly worse).

Yes steppers usually are not precisely manufactured and the steps aren't quite equal, and within each step the linearity of microsteps isn't great due to the pole piece design not being highly sinusoidal (they are just flat teeth usually). The phase angle between the A and B windings can be significantly different from 90 degrees too.