Adding servo issue

[pswindler]

I am making a automatic nozzle wiper that is using a servo to articulate. the problem is when i turn on the servo function in Configuration.h it errors out while compiling the the firmware. i have tried it on the last 3 firmware releases and it errors out on all of them. here is the part in configuration.h that i need to change but it wont let me. I need to turn on the function by putting True, after the FEATURE_SERVO command.

Code: Select all

/* ======== Servos =======
Control the servos with
M340 P<servoId> S<pulseInUS>   / ServoID = 0..3  pulseInUs = 500..2500
Servos are controlled by a pulse width normally between 500 and 2500 with 1500ms in center position. 0 turns servo off.
WARNING: Servos can draw a considerable amount of current. Make sure your system can handle this or you may risk your hardware!
*/
#define FEATURE_SERVO 0
#define SERVO0_PIN 11
#define SERVO1_PIN -1
#define SERVO2_PIN -1
#define SERVO3_PIN -1
#define FEATURE_WATCHDOG 1 

[joe]

You could try and put a "1" where the "0" is instead of true. Shouldn't make a diff but give it a go.

[Eric]

If you used True, then it's a case issue. It's true, all lower case. But what joe suggested should work as well.

If that's not it, we need more information, like the actual error messages. They may be a bit cryptic to you, but us software types will generally have a clue.
If you give us code snippets to analyze, give us the modified version....far more useful than something that isn't broken.

[pswindler]

Yeah a "true" and a "1" give the same result. it looks like this is the error its giving me.

collect2.exe: error: ld returned 1 exit status

Not sure why it wont give me anything specific. i clicked on the copy error messages button but it gave me a huge amount a compilation data, this is just the last this before it fails. I assume anyone that try this will get the same result. could be a error in the way seemecnc programmed the firmware? is there another way to get my servo working?

[geneb]

I would suggest that you post the error data, not just the last line.

Think of it like this - a doctor sends a blood sample off to a technician. The tech performs the test and hands you a detailed, 20 page report of the results. You in turn hand over the last sentence of that report to the doctor and expect him to tell you what's wrong.

g.

[Eric]

What geneb said....the red text in particular is the interesting part. However, even that one line tells me it's failing at the linker stage, which means the actual compiling worked.

Anyway, I downloaded a fresh copy of seeme 0.92 from their site and compiled it. Then I enabled the servo feature and compiled again. Worked fine using the Arduino 1.6.9 IDE that I had loaded. (By worked, I mean compiled and linked without error. I didn't actually try to use the servo feature.)

So I went and got the most recent version of the IDE (1.8.0) and tried again. And I now see your error, I think. The errors of note are multiple instances of (They're red in the actual IDE, so easy to spot, but don't be afraid of copying the entire block of compile info.):

Code: Select all

`stepperWait' referenced in section `.text' of C:\Users\Eric\AppData\Local\Temp\ccbAU07Q.ltrans13.ltrans.o: defined in discarded section `.text' of C:\Users\Eric\AppData\Local\Temp\arduino_build_644034\sketch\HAL.cpp.o (symbol from plugin)

So, my advice to you is to simply go get an older version of the IDE from the arduino site. 1.6.9 worked for me, but you could go even further back.

------------------------------------------

But if you're interested, I also know where this error is coming from. The 'stepperWait' is declared in HAL.cpp, but all the C code that used to use the variable has been replaced with assembly code blocks for efficiency's sake. The problem is that there are NO non-assembly references to the symbol left, so it got discarded as unused data. Which is fine, that's a good thing in most cases and is supposed to happen. The fact it didn't do it in older versions of the IDE isn't really a bug, although it sure feels like one to you. It worked before by luck of implementation, not because it should have. The mistake is arguably in the code...whoever converted C to assembly code should also have added an explicit directive "__attribute__((used))" to protect that variable.

But you didn't really need to know that, did you? Going back a few versions of the IDE is actually a fairly common fix for new and unexpected problems.

(edit- had typoed 1.6.9 as 1.9.6. Fixed now.)

[pswindler]

you guys are smart! thanks so very much! my servo is moving now! once i get it dialed in i will post info on my protect. The only other thing i had to do was define servo2 as pin 5 and it works great! i am getting a bit of stationary jitter but that is probably due to the cheap servo?

#define FEATURE_SERVO true
#define SERVO0_PIN 11
#define SERVO1_PIN -1
#define SERVO2_PIN 5
#define SERVO3_PIN -1
#define FEATURE_WATCHDOG 1

[joe]

i am getting a bit of stationary jitter but that is probably due to the cheap servo?

That can be caused by a voltage issue- see if you are getting even voltage. It may be fluctuation from the hotend and heated bed constantly changing their voltage demands.

[pswindler]

I did some tests and turning everything off did not change the jitter.

But I have a new issue in the gcode program. The M340 commands will execute but it will skip past all the gcode and perform all the m340 commads in rapid order. So it will perform both moves so quickly that the first move hardly has time to complete, i have tried using delays but after the delay it skips right to the next m340 command then will go back and complete the gcode in the middle. not sure why its doing this?

Code: Select all

G21 ; set units to millimeters
M107
M104 S250
M190 S30
M109 S250
g28
T0 ; set the active extruder to 0
G90 ; use absolute coordinates
M83: Set extruder to relative mode
M340 P2 S1600
g1 f10000 z40
g1 x-135 y-20 
g1 f1000 e15
g1 f1200 e-6
g1 f10000 x-135 y-10
g1 f1200 e-1
g1 f10000 x0 y0
M340 P2 S620
g1 z0.4
g1 f1200 e7
M340 P2 S0
M82 ; use absolute distance for extrusion

[joe]

Your g1 moves should be capitalized. G28 ....G1 X100 etc.

[pswindler]

In my machine changing the case of the g's has no effect, so the problem remains the same. it skips past all the gcode to the next M340, but still proforms the gcode after the M340 it skiped to.

[Eric]

I checked the code in gcode.cpp. This firmware parser will accept either upper or lower case letters. But it has been a gotcha in the past, and may still be on other products.

What you need to understand is that motion commands are queued, at least until the internal buffer is full, and gcode processing continues. Apparently servos are implemented as immediate execution, not part of the motion queue. So what you need to do is insert wait instructions so it will wait for all moves to finish before proceeding, like "G4 P0" (or alternative "M400"). If you need a delay after the move, or between servo actions, you can use the G4 argument to add wait time.

You mentioned trying delays, so sounds like you may have already tried this, but I'm guessing you put them in the wrong place. Put them just before each M340 commands, not after.

[pswindler]

Thanks Eric! That worked flawlessly, i was putting in my G4 after the M340, once i switched them it workd great. i still dont fully understand why it makes a difference thou? You guys are great at problem solving!

[pswindler]

I read though your post again and now i understand why it being before or after makes a difference, you explained it great! i just read it too fast the first time thanks