I got most of the parts made for my frame this weekend, I'm hoping to finish up and be able to do some assembly next weekend so maybe I can start software playing soon!
I was reading Ned's new manual the other night and one thing occurred to me and I thought I'd bounce a couple thoughts and an idea off of the group.
Ned kinda makes the dialing in of the taping algorithm look a little monotonous. Basically he's just adjusting the pole hole entry and maybe the tape width entry to get things right.
First I wondered why this was necessary as it's pretty much just geometry. The old garbage in / garbage out saying came to mind - the geometry should work if given the right starting data, so if things aren't working and need tweaking then it's probably because the starting data wasn't right. Ned seems to be making the effort to give good data though. However, if one thinks about it it makes sense - it's a mechanical system with lots of parts, angles, etc. and nothing is perfect so there's always going to be an error. To correct that error Ned is using trial and error. The pole hole entry I'm sure is just adjusting the amount of time the shell is rolled straight before the skew is made - i.e. it's just adjusting the diameter figure. Adjusting the tape width is just adjusting the angle of the skew, which is also tied directly to shell diameter.
Currently the software calculates it, the mechanics corrupt it a bit and then Ned trial and errors to dial it in. Nothing wrong with that, it obviously does work and it really only needs done once for each particular size of shell casing, but I was thinking that we may be able to help zero in on the proper figures quicker.
Basically it comes down to how many steps make a complete revolution of the shell. Shell diameters, roller diameters, ratio between them, etc. don't really matter - what matters is the final amount of steps needed for one shell revolution. If you know that then you know when to skew the tape and at what angle to skew it and everything should fall into place.
What if we installed a pen to mark the path the shell takes and then created an option in the shell configuration part of the software where we could run the motors manually. Run them slowly and watch the pen and when the shell makes one complete revolution and just as the lines meet you stop the motors -> now the steps for this particular shell in this particular frame are known. The math should now work with little, if any, tweaking.
Thoughts, comments, suggestions? Am I on the right track with the algorithm here (i.e. it all boils down to the number of steps for a complete shell revolution)?
Edited by PyroSam, 02 December 2012 - 02:16 PM.