Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review code comments from Mike Lawrence #1

Open
clough42 opened this issue Apr 19, 2019 · 6 comments
Open

Review code comments from Mike Lawrence #1

clough42 opened this issue Apr 19, 2019 · 6 comments

Comments

@clough42
Copy link
Owner

Mike left a comment on YouTube:

Mike Lawrence • 2 hours ago
@clough42

Did a quick look at the code. Would you prefer comments on GitHub?

Since this interrupt is modifying
this->currentPosition--
don't you need synchronization (a semaphore, volatile, atomic_int, etc);to prevent main thread calls to
incrementCurrentPosition(1)
from losing the ISR change?

this->currentPosition--;

I noticed floating point constant expressions in your code.

if( count > _ENCODER_MAX_COUNT/2 ) {

rpm = count * 60 * RPM_CALC_RATE_HZ / 4096;

Check the assembler code to see if it's doing the division at runtime. Some compilers defer floating point math to runtime to avoid losing precision. If that's true then you can eliminate this work by doing the divide during initialization.

create a new constants (not macros) for these values and set once:
_ENCODER_MAX_COUNT/2
60 * RPM_CALC_RATE_HZ / 4096

You can shorten

if(reverse ) {
this->feedDirection = -1;
} else {
this->feedDirection = 1;
}

to
this->feedDirection = reverse ? -1 : 1;

switch( this->state ) {

you can do a fast exit if no work
if( this->desiredPosition == this->currentPosition ) return;

This code is not needed since the next line set previous:
if( rpm > 2000 ) { previous = current; }

@clough42
Copy link
Owner Author

Removed the dead rpm>2000 code.

@clough42
Copy link
Owner Author

I think the race condition is real. Possible solutions:

  1. Disable interrupts while calculating and setting the new value.
  2. Use another register to dispatch the update to the interrupt handler.

@davidgeorge222
Copy link

davidgeorge222 commented Apr 25, 2019

As a thought,
would it be practical to work out the spindle speed and the desired lead screw speed
then use a timer to provide stepper drive signal as a back ground interrupt then the main program error checking?
Also if you need PCB / Schematic / hardware help let me know
Other thought I have is what happens if the lead screw stepper fails to step (lack of torque etc)
is there an encoder to monitor this?

@clough42
Copy link
Owner Author

@davidgeorge222 This is possible, and this is the approach that many people have used for this kind of controller. On this particular TI DSP, it's usually done with a high-res PWM peripheral. It's possible to set up the PWM at the expected frequency and then interrupt on every pulse to make adjustments.

I haven't gone to that level yet, because it doesn't seem necessary. There are lots of details to work out in the electronics, the motors and controllers, the mechanical drivetrain, the user interface, error handling, safety, fault condition handling, etc. At this point, I have code that works to calculate the ratios, and I want to get all the other stuff working before spending too much time refining the software.

Making the software perfect doesn't make much sense if some other element of the system ends up causing a top-down conceptual redesign. Better to solve the other problems first, and then come back to refine the software.

@davidgeorge222
Copy link

@clough42 sounds like your all over this.
If your running into problems with the electronics or motor drives let me know, as that's far more my thing than doing software.

@clough42
Copy link
Owner Author

clough42 commented Nov 11, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants