Brother TC-225 / TC-229 adventure!

thanks, that should do nicely.

so, I think, all the key functions of this machine are nailed down in terms of knowing what wire goes where, etc.

tomorrow I'm going to make up more permanent wiring for everything, and get all the atc inputs and outputs wired. I only had enough wiring today to run 1 axis at a time.

goal will be to by the end of the day, have xyz/s working as they should with their limits and homes and alarms and torque meters and thermal sensors all happy and be able to run a program.

then, if theres hours in the day left, try to make the atc work as its intended with the W axis trickery.

after that, its some extra io for coolant solenoid, air blast, door interlock, and uh, lights? they go through the io. why? I have no idea. I don't really have to do this I guess, I can just tie it to main power, or to a switch.


got a question on ballscrew compensation. with the drives powered though, I was able to measure that I have .0006" play in the x. either in the ball nut or the bearing block. its pretty lose play, I can push the table with my pinky and it moves. cuiriously, it moves back consistently as well, as if its sprung (maybe by a seal).

I also noticed that in the original control it has a screw map. many zones of +2 -4 settings, etc etc - which on that machine I believe are microns but I'm not fully sure on the unit. backlash compensation was oddly set to 0. I see that Linuxcnc has a screw calibration file, would this be similar? I'm going start by leaving It alone, but eventually I will want to get it mapped in to make things as precise as I can.

ive used backlash compensation in mach3, and turned it off cause I found it made things worse than with no compensation - it wasn't consistent. is the linuxcnc version of this any better? (I imagine the best route is to just repack the screw to try and remove backlash entirely)

some progress, and a roadblock.

I mounted the computer and the mesa board into the control cabinet all professional like
started making up proper clean shrink wrapped cables.

go the y tuned, then tried the z...

disengaged the brake on machine start and we get a red light on the servo - an error of some kind. tried combinations of no brake, yes brake, using the cable from the X (which we know works). always error. of course the motor does not move.

swapped back to the brother control and all drives error. restarted and error gone, all drives fine.

so at this point, I'm just a little confused. I don't see any wiring mistakes or config mistakes that would make the z error. things I still need to check

- rechecking all wiring - it was midnight when I did this and I was sleepy
- reversing the enable - maybe the z is backwards?
- checking to see is the brake signal is somehow tied to the drive - doesn't seem to be

anyone have any other thoughts as to why the z may be different from the x y and spindle?

thanks

heres a video that describes the tool change flow of the new brothers. something to strive for - minus the 2200ipm rapids and 2G acceleration - we only hand 787/590 on this machine. the other one (tc229) which well get to later ha 1470ipm and 1G rapids though.

ihavenofish wrote: I also noticed that in the original control it has a screw map. many zones of +2 -4 settings, etc etc - which on that machine I believe are microns but I'm not fully sure on the unit. backlash compensation was oddly set to 0. I see that Linuxcnc has a screw calibration file, would this be similar?

Yes, very similar. The numbers are absolute axis position, and actual position on either side of the backlash. So it corrects the screw and attempts to control backlash at the same time.
See COMP_FILE and COMP_FILE_TYPE linuxcnc.org/docs/2.7/html/config/ini-co...s__lt_num_gt_section

ive used backlash compensation in mach3, and turned it off cause I found it made things worse than with no compensation - it wasn't consistent. is the linuxcnc version of this any better?

It probably isn't. The problem is that the controller only knows which direction the axis is moving, not which direction the cutting force is acting, or if that cutting force is enough to move the table.

It works better on lathes, where cutting force direction is much more consistent.

I think the non stop chip to tool change can be done by swapping to W axis right from the last z position. w and z will share coordinates, so we don't need to hit home z again and could use g64. so:

--- last line of code before tool change
M3 S0.1 (fast spindle stop from 6000 in 200ms)
M5 (spindle cut)
issue tool change command
// swap z to w - and swap spindle to c (instead of the normal orient for now cause I can wrap my head around it)
// spindle encoder needs to be looping a count to know where the index is at all times when running in normal mode
--
G64 (so the moves are continuous)
G01 W17 (home of z/w) C0 (home of spindle) F590
G01 X? Y? (pre stage next positions in program) W20 (home of atc) F590
// rotate carousel (should we make this an axis?)
G01 W17 (home of z/w) F590
G01 W? (next Z position in program)
G61
// swap W back to Z, and C back to spindle
M3 S6000
--
---- back to code

were still likely a few days from getting to the atc finer points, but I'm thinking ahead

andypugh wrote: It probably isn't. The problem is that the controller only knows which direction the axis is moving, not which direction the cutting force is acting, or if that cutting force is enough to move the table.
.

I noticed I have seemingly less backlash under the brother control. peculiar. about 0.0003". either I measured wrong first time, or, the "backlash" is in fact spongy servo response. I think bad measuring