Advanced Search

JT wrote:

Ok that is what filled up the disk space... it needs to be off loaded as we are at 95% now.

That was the main reason for nail biting...
Made a post on mod forum for further processions.
Thank you.

Ok that is what filled up the disk space... it needs to be off loaded as we are at 95% now.

JT

linuxcnc.org/docs/html/
If someone updates the text of the documentation, then in 2.9.3-2099 everything is unchanged in iocontrol-v2
linuxcnc.org/docs/html/config/iov2.html

After much sweat and nail biting, we have a backup.
Damn it took what seemed like ages, and the stern warning not to switch to another tab or window was very big.Could not change the logo as there is no FTP or SFTP access and that seems the only way. Strange...

Aciera post=312133 userid=25994You don't _need_ it, those are simply used to define the pose for (x,y,z,a,b,c)=(0,0,0,0,0,0).

[edit]

Actually I just noticed that you are not getting an 'axis' limit error but a 'joint' limit error. So the issue is that you have to adjust your 'MIN_LIMIT' , 'MAX_LIMIT' values in the [JOINT_1] section of your ini file. Note that joint1=0 has the upper arm in the horizontal forward pose as that is what is used in the genserkins model so you may need to adjust the limit values accordingly.
 

So the joint axis limits in this case are relative the arm posture defined by the modified DH parameters?

Aciera wrote:

I was actually picturing a remapped (ie currently unused Mcode). This would be a rather simple gcode remap where you could then use 'motion.digital-out' pins for the appropriate coolant flow.

Actually adding this to the source code will likely involve
a) a number of files in '/src/emc/rs274ngc'
b) pose the additional challenge of there not being a suitable NML command for all the different coolant variants you have in mind.

The issue at hand, the lack of NML commands is a problem that requires a lot of extra effort for every retrofit that could be solve once and be done with. 

spumco wrote:

Aciera wrote:

I was actually picturing a remapped (ie currently unused Mcode). This would be a rather simple gcode remap where you could then use 'motion.digital-out' pins for the appropriate coolant flow.

Actually adding this to the source code will likely involve
a) a number of files in '/src/emc/rs274ngc'
b) pose the additional challenge of there not being a suitable NML command for all the different coolant variants you have in mind.
 
This is what I did for my non-standard cooling stuff.  Just cooked up some Mnn.ngc files to take care of stuff like spindle taper air blast, washdown, and multi-mist nozzles on my gang lathe.

are you at liberty to share those mappings ? 

Aciera wrote:

I was actually picturing a remapped (ie currently unused Mcode). This would be a rather simple gcode remap where you could then use 'motion.digital-out' pins for the appropriate coolant flow.

Actually adding this to the source code will likely involve
a) a number of files in '/src/emc/rs274ngc'
b) pose the additional challenge of there not being a suitable NML command for all the different coolant variants you have in mind.
 

This is what I did for my non-standard cooling stuff.  Just cooked up some Mnn.ngc files to take care of stuff like spindle taper air blast, washdown, and multi-mist nozzles on my gang lathe.

If you don't have ~5V absolute between STEP+/DIR+ and STEP-/DIR- (0 ..3)
when unloaded, that means the U5 or U7 (or both) are bad. This is because say STEP0+ and STEP0-
are inverted  copies of the same signal, so regardless of signals further back, there should
always be ~5V (no load) between them.

Also U7 show obvious signs of overheating. Typical reason for this is accidental connection of the
step/dir signals to a voltage outside the 0 to 5V range.

You might check the STEP- and DIR- pins to see if U5 is OK
 

Aciera has a good point, this needs to be sorted out.

I used an oscilloscope to check the step and dir signals, nothing going through. Is there a way to verify those ICs are the issue, or do you just know they are the most likely failure point?

foam wrote:

... I have a Probotix box with motors,...

Pictures of it, inside?
The chips should be in the control box.

@Hi Julian,

As i speak for the programming world, i suggest programmers love to describe a line, arc or spline using a few points.
As memory efficient as can be.
But i get your point.

The error i was getting, i think i figur it out.

The arc function that get's the current point on the arc does this not
by giving it a 0-1 progress.
Instead a 0-arclenght input is the way to do it.
So here i was wrong. But it's also poor commented, so i could not know it so easy.

OK glad that's at least partially sorted out.

Note that the index signal does nothing unless index enable is set true
(LinuxCNC sets index enable true when it wants to search for index)

You can test index operation by hand running LinuxCNC, and

halcmd sets spindle-index-enable true

Then rotating the spindle by hand. When the index is detected, 2 things should happen:

1. spindle-index-enable should change to false

2. the spindle position should be set to 0

Well today has resulted in some good things. I did change the Post Processor in SheetCam to LinuxCNC and created a G-code (2 one with NGC and the other with TAP). TAP not working very well but the NGC did, But I still got the Parse error on the load. And it also had a menu come up stating to insure the tool was set. Well removing the line in the G-code calling out what tool is used. That error went away. It now operated like the G-code generated by EstlCam. It loads and runs without errors. Not sure if there is a way for Axis to use a G-code with a TAP extension.  Of if there is another LinuxCNC post processor that does not place the tool number in the G-code.
Thanks for your help