Forum Replies Created
-
AuthorPosts
-
Derrick
MemberOK, I wanted to tag up now that I have ran a number of parts with the new firmware. Everything is cutting as it should, small holes, arcs, and large holes and arcs too. I am however still having issues with jogging the machine with both keyboard commands as well as mouse commands too.
The machine registers and commands sometimes… and sometimes it does not. It also sometimes stores the move commands and then sends them all at once. This is a “new feature” that started happening since I updated the firmware form my original posting. I can see the commands being sent in the serial port console, they however don’t make it to the TinyG. This also occurs when typing in commands, sometimes it takes them, other times I have to reenter then commands for them to be taken. Have you experienced this?
I am running JSON Server Version 1.83, I don’t think that this has been stated to this point, not sure if it matters. Is there a setting that I may have messed up? Maybe a priority or machine access setting that is causing this problem?
MemberQuick question before I update the firmware… is there any way to save the configuration of my machine?
ie… steps per rev, axis motors/directions/speeds?
I have had to go through and manually reconfigure these one by one a number of times now through this process and I really don’t want to do it again. Is there a faster/easier way?
MemberAnything new???
MemberThat code ran and produced arcs as it should.
Memberjust to add a little to the Z-axis “problem”, or lack there of…
Here is the product page:
http://openbuildspartstore.com/8mm-metric-acme-lead-screw/Line from the description:
Equipped with a large diameter that helps eliminate whipping and a high pitch which provides a quick 8mm translation for every revolution on the screw.MemberI tried loading your file, however it is way to big, I assume 25.4 times to big… no mater the mode that the I have the machine set to, it always opens in inch mode (which is obviously incorrect).
MemberOne rotation is equal to 8mm of travel… I aligned the split of the flex coupling to the front and then rotated until it was in the front again, and it moved a total of 8mm over the single rotation.
So it would seem that the machine is operating on the Z-axis as it should…
I will give your code a try and see how it goes, and report back.
One of the things that really has me baffled, is how it worked before the update and now it doesn’t… this indicates to me one of 2 things…
1. Something in the update changed that caused the issue.
2. The update firmware didn’t install correctly.Derrick
MemberArc issue and Z-axis travel issue (both).
I ran another part that I needed cut for a project… fortunately not a precision part so stock settings were OK.
Yes the Zaxis motor is direct drive. Personally I don’t really care that the z axis requires an odd steps per mm (4x what it should)… it works. I really need to get the arcs figured out, I have been unable to cut any parts that require accurate slots/tabs for nearly 2 weeks.
FWIW: after the $defa I input all parameters in mm mode, as you mentioned earlier that it was TinyG liked this better.
Here is a link to the latest dump file:
https://dl.dropboxusercontent.com/u/183607375/CNC/TinyGConfig_20151113.txtMemberI have completed the $defa process.
The problem still persists.
MemberOne other thing that has been happening since I updated that I forgot to mention is that the TinyG seems to miss commands…
What I mean by this is that if i select the jog button in ChiliPeppr and then move the machine using the arrows… it will start and stop or sometimes not start and require multiple key strokes to begin motion. This “missing” commands can also be seen when entering in command line, sometimes it will accept the command and continue, and other times it is like the board is not accepting commands at that time and I have to reenter the commands. This is not something that it did before.
Member1. Double check your motors – are they 1.8 degree Step Angle or 200 step per revolution? That is typical, but 400 step (0.9 deg step angle) do exist?
That still would not explain your necessary *4 setting of $3tr, but would introduce a /2 error.I double checked the documentation that came with them X/Y motors as well as the Z motor and all four motors are 1.8 degree step angle.
2. Please try this mini test. Put your tinyG into mm mode (send a G21 command on the Serial Console), then jog 10 mm, 1mm at a time. We are testing to see if for some reason tinyG’s mm to inch conversion is broken. If jogging 10 times, each 1mm, only moves about 2.5mm (10/4), then the mm to inch conversion is broken.
I completed the mini test and all is well, at least well in the sense of a 1mm jog command is equal to a 1mm travel in the Z-axis. The most it was ever off in the 10 moves was .05mm on the first move (and I think this was primarily due to my calipers settling a little bit. after the 10x 1mm jog commands the calipers were reading 10.01mm with 1mm steps along the way.
I will continue on with your recommendations and report back.
Derrick
Member1. With your current Parameter set, rerun a quick test that confirms that commanding Z to move 1 inch moves Z by 1 inch (or, as you reported, 0.9996″)
I assume you are using a 1″ jog?
Yes, I am using a 1in jog commanded via the ChiliPeppr interface. Doing so gives me a motion of .9995″. (I misspoke earlier, my digital calipers only give me the nearest .0005in).2. Change the $3mi parameter : $3mi=4 This cuts the number of microsteps per step in half.
I changed the paramater as stated (it was set to a value of 8)… however still attain the same results, .9995″ of travel when commanding a 1″ travel via the ChiliPeppr jog widget.I have completed the actions as requested and saved the parameter file, it can be located here:
https://dl.dropboxusercontent.com/u/183607375/CNC/TinyGConfig_20151109.txtMemberI don’t think I have addressed these two questions from you:
Is there some sort of filtering of the input .nc file prior to sending the code to the machine?
None that I am aware of. This has all really caught me off guard as everything was working perfectly before I made the upgrade… I only upgraded because ChiliPeppr had some popup that said that my firmware was out of date and reccommended that I upgrade.Are you using a post processor on CamBam? Which one?
It is currently set to “Default”.In an effort to remedy this issue I and because you enlightened me to post processing in CAMBam, I set the option to convert arcs to lines and the arc to lines tolerance of .001 (probably overkill on the tolerance)… needless to say I ran the code and all looks perfect, well except for that it isn’t working as it should with arcs.
Derrick
MemberI have updated the parameters as you suggested (see note below):
$3tr= 0.079
$xjm= 197
$xjh= 384
$yjm= 197
$yjh= 384Note:
I updated the $3tr paramater to .079 and while commanding a machine move of 1 inch up the machine crashed in the top of the Z-axis, so I reverted back to my previous value of 0.3152, I have measured the axis motion and when commanding a 1″ move I get .9996″ of motion.Perhaps a breakdown of my workflow will better assist you.In understanding where the problem is.
Workflow:
1. Design part in ProEngineer
2. Create a Drawing of my part/parts in ProEngineer
3. Export that drawing as a .DXF
4. Pull the .DXF into CamBam
5. Define the machining operations and then generate the G-Code with CamBam
6. Drag the G-Code (.NC) file into the ChiliPeppr interface
7. Machine the partAs an aside… for trouble shooting sake to ensure that there isn’t just a anomoly with the specific part that has been the topic of discussion to this point, I have followed the above workflow on a new part composed of a number of circles with decreasing diameters to see if the problem persists or is just a by product of smaller circles.
Link to DXF:
https://dl.dropboxusercontent.com/u/183607375/CNC/hole_test.dxfLink to G-Code:
https://dl.dropboxusercontent.com/u/183607375/CNC/hole_test.ncLink to G-Code from ChiliPeppr Sender:
https://dl.dropboxusercontent.com/u/183607375/CNC/Hole_Test_CPsender.txtPicture of CAMBam viewer with tool paths:
https://dl.dropboxusercontent.com/u/183607375/CNC/Hole_Test_CamBam_Viewer.JPGPicture of ChiliPeppr viewer:
https://dl.dropboxusercontent.com/u/183607375/CNC/Hole_Test_ChiliPeppr_Viewer.JPGPicture of what the machine actually cut:
https://dl.dropboxusercontent.com/u/183607375/CNC/Hole_Test_Results.jpgI think that it is safe to say that the issue that I am experiences remains… hope all this helps to further diagnose.
Derrick
MemberI tried to use the widget at first, however it obviously was broken, after that I manually entered them in via command line to match what I had saved as the dump pre-update.
What really has me baffled now is:
– The DXF is correct
– The .NC file is correct
– The Chilipeppr viewer is correct
… but the G-Code (as-run) is incorrect.Is there some sort of filtering of the input .nc file prior to sending the code to the machine?
It is however good news that the machine cut exactly what and where it was told to.
I don’t recall changing the Z axis velocity (ZVM), upon looking a little deeper, I think I must have 787mm is approximately = 31in
Yes, I spent a considerable amount of time commanding motion and then measuring the result tuning travel per step.
The Leadscrew on the Z-axis is an 8mm from openbuilds…
http://openbuildspartstore.com/8mm-metric-acme-lead-screw/Don’t have a clue about the jerk settings… that is what they were pre update and the machine was preforming flawlessly so I ensured that all was the same.
-
AuthorPosts
