LaosLaser / Firmware

Embedded software (firmware) for the laser system and components, including configuration files
27 stars 27 forks source link

USING LAST FIRMWARE HAVE PROBLEM WITH XHOME SWITCH #50

Closed JSilvaGlez closed 9 years ago

JSilvaGlez commented 9 years ago

Hi. Before worked fine the homing EndStops. When I have installed the last firmware de xhome signal dont work fine. Yhome signal work fine. Its xhome source changed ?? Anyone have the same problem??

peteruithoven commented 9 years ago

Could you town down the upper casing please? You come over as shouting, exacerbated by the multiple question marks.

I did notice that since the softlimits update it uses new config settings. Probably x.min, x.max etc. I also see this in the code: https://github.com/LaosLaser/Firmware/commit/08af452056eb7c38a318298c4f79f1488021d774#diff-f5422064a1192019a44c16f9d4badee0R190 https://github.com/LaosLaser/Firmware/blob/08af452056eb7c38a318298c4f79f1488021d774/laser/global.cpp#L142 Maybe you can recheck these values?

joostn commented 9 years ago

Yes that's probably it. In your config file: y.home should be inbetween y.min and y.max Or you can delete y.min and y.max if you don't need the bounds checking.

JSilvaGlez commented 9 years ago

Thanks. I managed to homing correctly. But the function ORIGIN, MOVE does not work move. i dont know why. I have Bedheigth uknwn. Im looking for whats is the problem.

jrv commented 9 years ago

joostn wrote: y.home should be inbetween y.min and y.max

I think that's not how it's supposed to be?

y.min should (at least in my view) be the 0-point of the workfield of the machine. My endstop is not at 0, but lower, outside my workfield. I think it's normal for y.home to be smaller then y.min or bigger then y.max?

joostn commented 9 years ago

Hi Jaap,

Depends on how you look at it: when I implemented this I considered the boundaries to be the absolute physical boundaries of the machine (i.e. when the cutter head would bump into something). LaosMotion will refuse to move to any coordinates outside this area. So it's the physical movement boundary, not the work area boundary. The home position will always be within this boundary of course.

Treating it as a work area boundary instead should not be that difficult, basically this would just mean that the boundaries need to be ignored while moving to the home and rest positions.

joostn commented 9 years ago

Actually looking at the code it seems it should even work if the home position is outside the limits. It will move to a 'safe' position (withing the set boundaries) immediately after homing.

No time to try now though.

joostn commented 9 years ago

@JSilvaGlez : Bedheigth uknwn means y.min and/or y.max are not set. You need to set them to the minimum and maximum y coordinates (in micrometers). And it's important that the same dimensions are set in Visicut (but in mm there). It needs to know this because visicut treats upper left as (0,0) while Laos has lower left as (0,0) so it needs to know the height (y) of the bed.

JSilvaGlez commented 9 years ago

OK i will try de next monday. close #50

jrv commented 9 years ago

@Joostn

I consider bumping into endstops something that should only be happening during the homing procedure, that's why I define it to be just outside the boundaries. But that might indeed be a matter of taste. It works for me when x.home > x.max, so no problem here.