7i97+8i20 error function not found

Tried the "setp" commandline trick but for some reason did not have luck with it.. But, It is now maybe right and working (atleast almost)! Tried to start to swap UVW wires place. They were originally marked and with uvw (fanuc), wired like it to the 8i20, the acts were as described earlier. Second i tried to put the wires like 8i20 UVW - VUW servo, it maybe changed a little, but shaked the machine like hell if remember correctly. Third time i put them UVW - VWU, and with only "F" mode it worked pretty much like it should (NOTE: had to change encoder scale from negative to positive, and rev from 1 to 0. Without this it would not move, only stays in one position) I could enable the machine no matter of the servo position, soon as enable hits the servo seemed to have full torque. When machine was turned of and the axis were rotated by some amount (tested several times), it always stays on its position and moves when jogging like should. Added mode "fq" and used all the rest bldc component pins for quadrature encoder (like I had before as in the hall i posted), and it seems to work. Only when i tried "fqi" mode it would do the servo jumping stuff again, maybe at some points it stopped doing that. I am pretty sure it is because of the index hunting and something is wrong according to that..

But to the next question, how about homing with fq mode? It just trusts the home switch with the values? Can I get it as close as index homing? Or do I need to still use index for homing, but only in some other way written to hal.

Thanks for the help Andyimage missing /media/kunena/emoticons/smile.png

  current hal. Only X axis grayscale for now, have to wire rest of the gray scale inputs tomorrow.
 

I would suggest using fq mode, as the encoder index doesn't really add anything extra on top.
I don't know if Fanuc use the encoder for commutation, the 16-step commutation from just the grayscale sensors is probably fairly smooth compared to the normal 6-step that hall-sensor motors use.
And the pure f-mode should be very "robust", it can't lose it's position.

You can use the encoder index for axis homing without using it for commutation.

Played more with this few hours tonight. Wired all 3 axis grayscales to 7i97 0-4 encoder inputs and putting jumpers to single ended position. abz inputs and coder power and ground goes to 7i85.

Tried to use fq mode, swapped motor wirings to all combinations and tested them all, maybe one of them would work the best, others not so good or not at all. It usually worked right a long time just by changing the bldc scale -+, or rev 1/0. Tried to jog it in different speeds, enable on/off, e-stop and other things that used to trip it in a way that caused servo runaway. Otherwise was really good, but sometimes when powered off couple minutes and enabled, the servo would runaway. And when it worked but ferror/error in ini was 0.1, there would be a join follow error immediatly in X- direction, but not in X+.

Had same settings to X and Y axis (same servos), but Y axis was more prone for runaway. The weird thing there was, it usually became ok for a small amount of time when switched the rev... And then in some time it started to runaway at powerup. 

Otherwise it looks like the grayscale works good, does not matter if the axis moves when powered off, the position will not change at all in enable. Z axis worked also sometimes, but usually it just dropped so had to hit e-stop.. Starting to look that maybe i should just use the F mode without quadrature, for safe operation.

Now i have really weird issue, what i thought would have been simple fix but once again, it was not image missing /media/kunena/emoticons/laughing.png

So, Trying to use just f mode on x/y axis, (z also when i get the y working first) been testing only X and Y axis now. When moving X+- on linuxcnc servo works like it should, but when moving Y+- there is rough vibration and jump. And what makes it weird, it does not matter which servo, servo drive I swap wires. real y axis servo works also perfect when wired it so can move it in hall, x real servo therefore jumps..

What have been tested/done so far according this problem:
-New hal part for Y axis (x axis copied, changed only all the numbering and x/y markings to suite it)
-tested all three  8i20 across swapping wires
-Changed all encoder cabling across
-Changed sserial cables across
-Moved Y encoder input on 7i85 board from enc1 to enc4
-tried swapping servo power wires across, all combinations thorough on Y axis servo
-inspected all the encoder wiring so the pins match and no shortages

So for me it feels like a code/hal issue? Think that all hardware/wiring has been tried that could matter

 

Today I tried to change x-y grayscale wires inputs between them, no affect. Also changed all of the x-y in hal between them, no affect. Also tried to change 8i20 in hal across, no affect. The problem always stays in that output linuxcnc Y- or Y+ tries to move, X seems to be working just like it shouldimage missing /media/kunena/emoticons/sideways.png

Have you done the PID tuning?

What I would do (and it isn't always easy) is to first make sure that the servos turn smoothly when given just a current command (they need to be disconnected from the axes for this).
Once you can spin a motor smoothly and at both low and high speeds, and can reverse it just by setting a negative current, then you can move on to tuning the PID controller that converts position error into motor current commands.

Disconnect a coupling, or remove a belt or something, load up LinuxCNC and then open a HAL window
etc. "exit" to finish and note that you can use tab-completion for the pin names. ie, type hm{tab} and you will get hm2_5i25.0. or similar auto-typed, up until it becomes ambiguous.