Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: dresda on January 21, 2013, 09:58:46 PM
-
Using DSPMC, is there a special G code to sink the spindle and feed before threading or do I just leave it in g95, Rufi at at Vital systems with the DSPMC said you have to trigger an LED with a G code when threading then turn it off when finished...
ray.
-
What are you meaning by threading? Single point lathe threading or rigid tapping?
Either way the control itslef needs to do the actual motion.
Hood
-
For lathe threading see the lathe manual for G32 defnition. Also have a look at G94 & G95.
RICH
-
Sorry, lets start again. I know all about threading single point on the the lathe like using g76 etc and not having to turn led's on and off, don't know what Rufi is on about, that's the problem with trying to marry two systems together, it's a pain. This is what his manual says:
Mach3 Threading Bug Workaround:
DSPMC plugin uses LED 1370 to workaround threading logic problem with mach3.
In your G-Code program, turn on LED 1370 right before the threading g-code command and turn it off after the threading cycle is done. This will cause the programmed RPM +20% to be sent to Mach3 instead of true RPM during the threading cycle. This makes sure mach3 will generate correct feedrate for Z axis. Once this LED is off, true RPM will be shown on mach3 spindle rpm DRO.
Also he telsl me I can't run 2 hanwheels at the same time and to wait for Mach4 to out, don't if that's the capability of DSPMC or Mach?
ray.
-
Sounds weird, shouldnt be a problem with threading at all as other controllers manage it no problem without having to set rpm to some imaginary value.
Also regarding the MPG, that is a DSMPC plugin restriction I would think as although I have never used 2 MPGs there are people using the parallel port that do. It may be that the plugin interface cant do it.
Hood
-
Use two mpg's here via the PP and have no problem's at all with them.
Mach allows for adjustment of the feedrate depending on what the true rpm reading was so it can fix the thread if required
due to spindle slow down but will not address spindle speed up. You don't want some arbitrary value screwing up the next cycle.
That's what was meant by the vfd fighting Mach and thus setting the spindle rpm manualy and letting the rpm settle before threading.
If you so desire you can have a read of page 4 in the Threading on the Lathe write up as it explains the cycle in detail.
As you read that break down each step and consider how the rpm and also the Z axis move, or any other part of the system can and will affect the threading cycle. You threading will only be accurate as your lathe SYSTEM.
RICH
-
Rich, think the latest driver for the PP can handle speed up as well, or at least I think thats what Art said on Yahoo. Dont use the driver myself so not certain.
Hood
-
Hood, would't know as i don't follow Yahoo anymore and still use a rather old version of Mach .....works too well for me to change. ;)
RICH
-
It was a while ago but seem to remember something about it anyway. As you say if its working then leave alone :)
All this is no importance to dreda anyway as he doesnt use the pp. Not sure why the DSPMC has to do that with the LED and spindle RPM.
Hood
-
My bad...didn't realise that he is using an external motion device.
Need to stop speed reading which i can't do anyway. ??? :D
RICH
-
I often suffer from that as well ;D
Hood
-
This is what his manual says:
Mach3 Threading Bug Workaround:
DSPMC plugin uses LED 1370 to workaround threading logic problem with mach3.
Well, I have a problem right here with the claim that there is a threading bug. I have been threading with G76 for a couple of years now. No problems, and the result matches good taps and dies.
This will cause the programmed RPM +20% to be sent to Mach3 instead of true RPM during the threading cycle. This makes sure mach3 will generate correct feedrate for Z axis. Once this LED is off, true RPM will be shown on mach3 spindle rpm DRO.
F a s c i n a t i n g . . .
Given that Mach3 drives X & Z axes synchronously for threading, I am not sure difference 20% in spindle speed will make. None at all would be my guess.
Equally, I find the idea of causing ' the programmed RPM +20% to be sent to Mach3' slightly incomprehensible.
I wonder whether the author of the comments has got the sync check box ticked in Mach?
Or am I just not with it?
Cheers
-
Could it be something to do with how the DSPMC handles threading?
It could be the DSPMC works by buffering the threading move, hence the 20% spindle increase to fool Mach into supplying a buffered feed.
-
What is LED1370? I find it a pain using half the mach parameters and half DSPMC parameters to make stuff work, I just don't understand what they are saying buy turning something on and off again.
-
it is a user LED that they are looking for, they have decided they must see that for some reason. What that reaon is I have no idea, you would have to ask them.
Hood
-
I called them and I have become a drag and I can't waste any more of there time, as I said to them I did post it on the DSPMC part of the forum but they didn't reply. I've only called about 3 times in the last month or so, just need answers, you read the part in the manual, they say mach3 has a bug, you guys say not. I wanted to use more than one MPG, they said wait until Mach4 comes out now I find out it's DSPMC can can only handle 1 MPG.
He did offer me my money back for the unit $1500.0 just might take him up on that.
Ray.
-
He did offer me my money back for the unit $1500.0 just might take him up on that.
What an excellent idea.
Cheers
-
Sorry "rcaffin" could you explain?
So after a slightly heated phone call with Vital systems they sent me this:
Attached are two files you copy to c:\\Mach3\macros\Mach3Mill.
Make sure you are using mach3mill profile.
You can then write your gcode like this:
…
…
…
M1370
Threading gcode ….
M1371
…
…
…
This will turn on and off led 1370 at proper place.
I assume all you mach3 users don't use this function.
-
Ray you are using an outside controller with Mach3 as the front end. THis has ALWAYS been trouble as the Hardware and software never seem to see it eye to eye as HOW to run functions properly.
It is NOT a Mach3 problem as I see it. AND I don't really see it getting any better UNTIL Mach3 builds its OWN controller that does ALL the functions that the software is capable of.
THAT is why most of us stick to the old LPT port. For the most part it does exactly what the software is capable of. Most outside controllers are a compromise.
AND as a side note Mach3 is NOT a Fanuc (;-)
Just a thought, (;-) TP
-
Why would you use a mill profile if it is a lathe? Something seems strange about that, is that the normal way in the DSMPC for a lathe? If it is then that will be why they can not do threading as a mill profile does not do threading.
Hood
-
Sorry "rcaffin" could you explain?
OK, let's start with some known FACTS:
1) Many of us with basic interfaces and mach3 are threading with G76 quite happily
2) It seems that the Vital interface does not work properly with Mach3.
In other words, introducing the Vital hardware stops the system from working. Terrry (BR549) summarised it quite nicely when he wrote ' trouble as the Hardware and software never seem to see it eye to eye '
This will turn on and off led 1370 at proper place.
I assume all you mach3 users don't use this function.
We do not even HAVE this function. But that is because we do not need it. Our systems work happily without it - but we are not using the Vital hardware. There's a message here somewhere.
I dare say the DSPMC unit works very well when you use their 'DSPMC .Net Managed Library for C#, C++, and VB'. I dare say the hardware does all it is meant to do. But the claim it is fully compatible with Mach3 clashes with the need to introduce kludges like the +20% and the m1370 macro.
Cheers
PS: I have been accused more than once of being blunt. Yup. I just haven't the time ...
-
dresda,
Seems like you are are on your owne. I am not going to question a manufactures way of implementing their
controller as they are responsible for making their device work with Mach. I also think that they should provide
the specifics of how that is done and support you in your efforts to use that product. We can only give you what our experience entails. Quess I am just echoing what a few others have already said.
wish you luck,
RICH
-
You are all right, and Hood, it's for a lathe, Rufi at vital said mill so now you know why I have to read between the lines all the time.
I thought Vital systems motion controller was a standard with Mach3 users and was a prooven unit.
I,m not comparing Mach to any other systems like fanuc, I think it's a great software for the price and that's why I am trying it out again.
Thanks for all your help.
-
The thing that puzzles me is if you use a mill profile, I would assume you have a mill screen loaded. If that is the case then you should get an error thrown by Mach if you try to command a G76.
I think the DSPMC is used by quite a lot of people but likely there are not as many using it on a lathe, in fact lathe users make up a very small proportion of Mach users no matter what controller, but its a growing number :)
Hood
-
hood,
I use mach3mill for testing all the time and I made a mistake when I sent him the instructions and wrote mach3mill instead of mach3turn.
For lathe we had to keep the rpm 20% higher than programmed inside threading gcode to get correct threading data from mach3. we use led 1370 to tell the plugin when to fake the rpm. because as far as I know, there is no way to know what is the next gcode command.
hopefully mach4 will fix all that and we wont have to fake any rpm.
yes most users of dspmc use it on mill, but some including machmotion guys have used dspmc on many professional lathe systems. I would say Andy must have done hundreds if not thousand of threading cycles to make sure it is working correctly with dspmc.
rgds
Rufi
www.vitalsystem.com
-
Rufi,
thanks for coming back and clearing that up, it certainly puzzled me how a mill profile could possibly work ;D
Are you using a single index pulse for threading?
I have only used 2 types of external controllers on a lathe , Smoothstepper (USB and Ethernet) and CSMIO/IP-S.
The Smoothsteppers just uses the single index pulse, nothing special is needed to be done for threading and it works very well and always has.
The CSMIO uses full encoder feedback and it has its benefits as well as issues, it does work well for the most part, for example spindle speed can be varied and even stopped and it will stay on track (think grossly underpowered spindle) but the pullout at the end of the thread is delayed and thus you get an annular groove being cut.
This is a Mach issue in the way it sends info out and the CSMIO has to wait for that info which causes the delay. I have discovered recently through my testing that an earlier version of Mach did things better as the pullout was almost instant but as yet I have not got info on what has changed in Mach.
Mach4 by all reports will be much improved with this regard, or at least I have been assured it will be by Steve ;D
Hood
-
Hood,
DSPMC uses full encoder for threading feedback. It modulates the Z feed with spindle RPM based on the encoder counts. so if you slow or stop the spindle, the thread will still be correct.
I have not heard about any delayed pullout issue. MAchmotion has done all the testing for DSPMC threading and they are also professional machinists. Andy has not mentioned this kind of problem, but I will check with him.
thanks
Rufi
-
Would certainly be interesting to see if it does or does not have the delay. Both the CSMIO and the Galil had/have that issue.
I talked to Steve (Smurph) about it and he said they couldnt find a way to get it to act right with Mach3 but the good news is he will be making sure things are much improved in Mach4 :)
Look forward to what Andy has to say.
Hood
-
Rufi, any word back on whether there is a delay or not in threading pull out with the DSMPC?
Hood
-
well here is what Andy says: (copying the conversation without his approval :) hope he won't mind )
"I have never seen any issues with threading on the hicon or the DSPMC.
Oh, I think I know whats wrong. He need to change how he programs the G76
the Q number is negative or zero.
10.7.18 Canned Cycle – Threading G76
Program G76 X~ Z~ Q~ P~ H~ I~ R~ K~ L~ C~ B~ T~ J~ to cut a complete thread.
X - XEnd
Z - ZEnd
Q -SpringPasses. (optional)
P - Pitch
H - Depth of first pass
I - Infeedangle
R - XStart (optional)
K - Z Start (optional)
L - Chamfer (optional)
C - X Clearance
B - Depth LastPass (optional)
T - Taper (optional)
J - Minimum dept h per pass (optional)
I think he needs to play with the "L" option"
hope this helps.
rgds
Rufi
-
Do you think it would be possible for Andy to make a quick video of the DSMPC threading?
Hood
-
Hang on... threading pull out, I can't even get the pitch right yet.
Ray.
-
Rufi,
I think he needs to play with the "L" option"
True.....BUT.......
The L ( chamfer ) in Mach is the number of spindle rotations in degrees over which the tool will pullout. So for L=90 that would be 360/90=1/4 revolution. For a fast spindle speed it could be impossible since there may not be enough time for a device and "system" to respond. The spindle needs to slow down. If a delay is present that would screw up the pullout.
I don't know where the pullout is done in the actual Mach code for threading and as such DSPNC would need to address it if it even can.
Not a Mach "bug" but rather just another item an external controll needs to address since it's playing around with a Mach's threading cycle.
Just a comment,
RICH
-
Ray,
Hang on... threading pull out, I can't even get the pitch right yet.
A bug or not a bug ......that is the question. ;)
Mach threading was fixed quite some time ago. There is no "bug" if it is used in the context of what was fixed and how it works. If the threading cycle is not working correctly for DSPNC then it is a problem with how the external device is trying to manipulate or control the threading cycle.
Rework is required to the threading code to address hardware / controllers which use encoders. One should not make a mistake and compare different controllers.
Would be interesting in what defined procedure DSPNC used for verification of rpm or feedrate accuracy.
RICH
-
Rich,
first the reply by Andy. I decided not to question his reply and just asked to see a video of it working instead ;)
The background of this is as follows. If using a single pulse for threading with an external motion device then it works well, usual caveats regards relatively stable spindle of course. If however using full encoder feedback to sync Z to Spindle then things are not so good.
The actual threading part works well on at least two of the devices I know that/have utilised it, the Galil and CSMIO, the DSMPC I am unsure how well it works. Where the problem is however is the end of each pass, the pull out is delayed whilst the plugin waits for updated info from Mach. There is no difference what you have the chamfer set to, well actually there is, the larger the chamfer the slower it MAY be on the update.
The spring pass amount I fail to see how that could even be considered to be relevant.
I asked Dresda in another thread regards the pull out and it seems the DSPMC also suffers from this issue, not surprising really as the guy who wrote the Galil Plugin is Smurph who is also now on the Mach4 coding team, so you would think if it could be done he would be able to do it.
Now here is something I found purely by chance. There has been a change in Mach and the plugin interface. I had an earlier version of Mach loaded as I had been testing something else. I had forgotten it was loaded and when I tried the threading in a new CSMIO plugin it was great, pull out was almost instant but the spindle override wasnt working. It wasnt until later I put 2 and 2 together and realised that it was the older version of Mach that had made the difference in the pull out and not the plugin. Sadly Brian is too preoccupied with Mach4 to be able to say what the difference is and whether it could be added to later versions.
Good news however is when eventually Mach4 Turn is done things will be much better regarding the plugin interface and Steve (Smurph) has assured me he will make it a priority to have the correct code in there for lathe threading using full encoder feedback.
Hood