I should probably post this in the ‘No judgement’ section, as I have probably misunderstood something with my problem but it might be a software problem, so I’ve put it here.
I’m trying to cut parts that are as similar to each other as possible, so rather than arrange them on a single piece of wood, I’m putting the stock on the Maslow in the same position and cutting with the same gcode file each time. This is because I have found differences in parts that are cut at different places on the work surface.For the job I’m working on these differences are too big. So far so good. I set my home position at 0, 100 and the gcode file cuts around (0,100). I drew lines on the work surface to show me where I should put the stock. I cut several parts and they all came out the same size and shape. All still good.
Then this morning I started cutting some more parts and I found that (0, 100) no longer lined up with the lines I had drawn. I have marks on my chains and so I know that the chains haven’t jumped, they have done a few times and it’s never caused the home co-ords to change. It looks to me like setting the home position doesn’t change the co-ordinate system, it just moves the home position. So how can (0,100) have moved? Is it really a fixed position or can it change somehow? My calibration seems OK as I have rejigged things so I can cut the gcode file in the same position and it comes out very similar to the other parts. There may be a Y scale increase, but I’m not sure about that.
That sounds really strange. You are 100% correct that the point (0, 100) should never move unless some part of the machine changes size. I’m not really sure where to start investigating this, but it sounds important to look into. What firmware and GC version are you using?
Hmm, I’ll check the version of the code tomorrow, it is quite old as I’m trying to freeze everything while I cut these parts that I want to be the same.
OK, I thought from what I was seeing that even when I change the home position the coordinates don’t change. OK, at least I’m not going bonkers.
I suggest making a back up of the ground control directory. I will send a link to a set of steps in a different thread. The reason for the backup is it would allow us to possibly dig deeper into this if needed at a later date.
OK, This seems to have happened to me again. This time I noticed that the home position has moved and the marks I put on the sprockets and chains aren’t now lining up. What I mean is that the marks on the sprocket aren’t in the orientation I put them at. I’m thinking that the firmware has lost the absolute position of the encoder. In fact, how does the firmware know where the encoders are when it is powered up? I’ve noticed a small amount of creep over time when the motors are off, surely the firmware can’t know this has happened if it is off? Also, if I just pull the plug on the arduino, isn’t the firmware going to lose the absolute position?
Is the way to try to keep this setup to always power off at the home position?
Where does the firmware think the sled is when it powers up?
On the basis of the encoders not being where they should be, I’ve done an automatic chain length calibration and (0,100) is back where it should be. So it does look like that was the problem.
Looks like I may do the chain calibration at power on each day…
This really sounds like a chain had jumped a tooth on the sprocket. Check that the motor mounts have not twisted, that the taut chain travels parallel to the sprocket and the work surface, and that the slack chain feeds parallel to the sprocket too. A chain jump happens too quickly to see, but with the router off you can hear the grumbling of a mis-aligned chain as it snags on the teeth, and a loud pop or bang when it jumps. In my experience it is more likely to happen on the top half of the sheet. Maybe run a test cut without the bit and with the router off and watch and listen.
I’m glad that it is repeatable because then I can probably replicate the issue and see what is going on.
Here is the way the system works in theory:
When the motor stops moving it waits for two seconds, then powers off and the current position is recorded into the Arduino’s non-volatile EEPROM memory which isn’t erased even if power is lost. When the machine is powered back on the position is recalled and it remembers where it is.
The encoder is not an absolute encoder (it doesn’t read a position in degrees), instead it is a relative encoder so it what we get are pulses as it rotates. In theory if the motor were to rotate while the Arduino did not have power we would lose track of position, but because the design of the gearbox does not allow it to be back driven this should be impossible.
I have two theories for things we could test:
We are writing to the EEPROM too early. I believe that we write the motor position to the EEPROM at the same time that it powers down. Do we need to wait even longer to ensure that it doesn’t have some momentum?
The value written to EEPROM is not being read correctly. There are limits to floating point precision, but I wouldn’t expect them to apply here. I tested this pretty thoroughly a while back, but it’s possible I missed something so I will check it again.
The maslow saves it’s position into eprom every couple of seconds, so if you
don’t turn it off too quickly, it should not loose it’s position.
If the sprockets are ending up turned to different positions, then either you
are loosing some encoder steps due to bad wiring, or you have redefined where
’home’ is and it’s going to the new location.
you should be able to do the manual calibration, which consists of you rotating
the sprockets to a known position, hooking the chains on in that known position,
and entering in what the length of the chains are at that point.
A wiring issue could result in the kind of issue you are seeing. If some of the pulses from the encoder are lost along the way the position could slip. I would try re-seating all of the connectors. Is there any chance you have a lot of RF in your work area? Is there something else near the encoder lines which could be causing interference?
Are you seeing a change in position only after powering the machine off and back on again, or does it happen while you are running a cut?
I’m pretty sure the chain didn’t jump. I’ve had many chain jumps and I know it has happened as I have marks on the sprocket and chain that align at the home position. when the (0,100) point moved the chain and sprocket marks were aligned but the cutter wasn’t at (0,100). The angle of the marks on the sprocket weren’t at roughly 12 o’clock though, so I think it means the zero point of the sprockets wasn’t right. (By this I mean the zero that is set by the automatic chain length calibration).
I’ve never seen this while running a cut, only after powering on and trying to cut the exact same part I’d cut the day before at exactly the same position. I do have a lot of noise, or did, as I’ve added filtering to the Arduino and router and also to the dust extractor and I see no problems related to that now. As the automatic chain calibration fixes the problem I think it is the position that is written to eeprom. I remember accidentally pulling the power to the Arduino and motors accidentally while cutting a while back, but couldn’t say whether it was just before the problem occurred. The explanation of how the position is saved is useful as I can now make sure I wait two second before powering off.
The encoder lines are running more or lss on their own, I don’t think this is an electrical issue, especially as I don’t see it during cuts.
Thanks for answering all those questions. I feel like we’ve got it narrowed down to an issue with the way the position was remembered when the machine is powered off. Best case scenario it was a one off issue as the result of a power interruption, worst case scenario it is a software issue which we can track down and fix.
Will you keep an eye on it and see if it happens again, or if it was a one time issue as a result of a power interruption?