Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: daniba73 on January 18, 2020, 06:33:56 PM
-
today we tried the mach4 lathe + CSMIO IP S+ ENC module.
the lathe has a mechanical gearbox.
we set the various interval values in Mach4.
and so far so good, it has been relatively simple.
the classic lathe operation went smoothly.
the laps programmed in the gcode, had little deviation from the real ones (about 5 rpm difference) having VFD we cannot expect the perfect value.
the real problem occurred with the G76 cycle.
the thread pitch is completely wrong !!
I will give a simple example.
in G76 program F2 as wire pitch (metric unit).
bitter surprise it was immediately noticed that in the CCS a value of about half of the programmed step is displayed.
to obtain the correct CCS with the thread pitch, we must deliberately confuse the parameters of the spindle in Mach4 and enter the motor revolutions equal to those of the maximum number of revolutions.
as a result, we deduced that an incorrect parameter was taken into account for coordination.
mistake is ours? where can we go wrong?
who uses CSMIO with Mach4 Lathe, has these problems?
tomorrow we will do other tests, I will keep you updated.
-
we did other tests.
correctly entered the values in the spindle boxes, therefore the turns are programmed / real (within a minimum space).
first anomaly, the Accel and Decel Time values are ignored.
The real problem lies in the coordination between CCS and droSpinRPM.
all the Fedds per lap (G99) are wrong !!!
The worst was with the G76 cycle.
to get the real step we have to deliberately give an incorrect value in F.
we were forced to divide the thread of the relationship.
example
2 / 0.517 = 3.868 (2=pitch 0.517=ratio)
therefore in G76 the Feed had a value of F3.868
understand immediately that there are big errors between plugins or Mach4!
however, including deception, we tried the thread.
the real step has finally been corrected!
another negative thing is that the thread is ugly.
exceeding the cycle of the wire to reach the right size, the triangle of the wire is slightly ruined, it does not always start from the same position !!
repeats several times and gradually increases the error on the triangle!
we are very demoralized and angry about this.
I declare that the mechanical and electrical parts are perfect, so the problem is only software !!.
-
no opinion about it?
no forum user uses Mach 4 Lathe with the CSMIO IP S?
-
I don't think there are many Mach4 lathe users (compared to mill users) but you have to allow more than 2 days for a reply to a question.
Not everyone checks this forum on a daily basis. ;)
Tweakie.
-
yes your speech is correct.
as I don't understand how Mach3 users don't switch to Mach4 lathe.
it's another planet! it's exceptional!
always for the reason that we are few, we should be listened to more, because we are testing on the field a relatively young software despite its 5 years.
as I discovered a bug in G83 I am detecting these anomalies in G76.
always in G76 there is an error regarding Q.
the Q of the second row is an increase in the first pass.
the Q of the first row is an increase in the subsequent passes.
instead it assumes the higher of the two Q values and keeps it for the whole cycle.
I'd like these things to be read and resolved by the software developers.
-
Hi Daniba73,
I understand.
I'd like these things to be read and resolved by the software developers.
Unless things have changed...
A quote from support; 'The helpdesk is the only way to guarantee official support from our team. You are welcome to post here seeking help from other users, but you will not likely receive a response from our team on this thread'.
I think that ideally you should submit a ticket (email) to support http://support.machsupport.com/en
Tweakie.
-
Do not use CSS DRO for anything to treading at ALL.
Use "Turn cycles" , "Treading".
Use 100 rpm and Pitch 1.5
Read the manual G76, put in the other values.
Run the gcode and "Feed rate" will show 150 mm, I think.
Cnckr knud
-
yes, it is exactly as you say.
G97 (fixed rounds) must be used for the thread, and so it was done.
on the CCS DRO if the current step were to be displayed, in my case it was 2 mm per revolution.
the problem is as explained above, I believe that the calculation is based on a wrong or unsuitable parameter to generate the step.
why I had to create the F with wrong value to get the correct thread.
I also tried to inform help desk.
-
I have made discoveries.
I did tests on the PC at home where I don't have a license or a controller, only Mach4 in demo.
in this way it cannot be influenced by any plugin.
as for the wrong step with the use of intervals, I think it is attributable to the plugin, because in Mach4 it seems that everything is correct.
you change the range, but the CCS value remains fixed on step F2.
as for the triangle of the thread that is ruined with multiple passes (without giving any increase) I assume that Mach4 is responsible.
I ran the same gcode 3 times in a row.
download the images and save them in a folder.
I numbered them according to the sequence to make the calculation or trajectory errors visible.
it is known that by changing the starting point, the thread of the thread changes and this is exactly what happens in Mach4.
NOTE:
if you load gcode and run it, you will notice the behavior of the letter Q.
it assumes the highest value and keeps it throughout the cycle, which is wrong.
Can developers be made aware of these issues?
especially for trajectory errors.
this is gcode:
%
(THREAD 20X2mm)
G99 (FEED REVOLUTION)
G61
T101
G97 S500 M3
G0 X22 Z2
G76 P010060 Q0.1 R0.02 K3
G76 X17.4 Z-5 Q0.2 P1.3 F2
G0 X22 Z2
M5
M30
;
-
I also tried to inform help desk.
I think you either contact the help desk or you don't - trying doesn't really seem to amount to much ;)
Tweakie.
-
hi, try to understand, i use a translator to read and write, sometimes some sentences are diverted.
Yes, I contacted the helpdesk.
if I have to be honest, I have more faith in you.
I will explain why.
up to now I have used the helpdesk service twice.
the first time about 1 year ago.
I had already warned of the collision problem of the G83.
answered a boy or a girl, now I don't remember well. saying it was not entirely clear what the G83 was doing.
I didn't answer anymore.
The second time I asked how to create macros for the mechanical range.
their response was to use M40 etc. etc. that I had to create it myself or ask on the forum.
-
in a virtual way I tried to make a thread using the G32 to understand who makes mistakes in the trajectories, Mach4 or plugins.
from video graphic everything seems ok.
as soon as possible I will make a test piece using this method.
the result should bring to light those who make mistakes.
-
Please contact the help desk by email. http://support.machsupport.com/en
Please describe the problem in as much detail as you can.
Mach4 is a fully supported product, the help desk is there to specifically help resolve any problems users may have with Mach4.
Please accept my apologies for being blunt in my earlier posting, I had not realised you were using a translator.
Tweakie.
-
do not worry.
I usually always notice when I start a post that I use a translator.
I am on your side.
I love Mach4!
I convinced 3 friends to buy a license.
it's beautiful software! and I want it to work as it deserves, which is why I am working hard to find the problems.
P.S. when I get the test result with G32 I will contact the helpdesk if necessary.
I must first understand who is wrong.
Mach4 or plugin.
-
Update the post with the results of various tests.
these were performed on 2 different lathe, mine and that of a friend (one of those that I convinced to purchase the Mach4 license).
the 2 machines have the same hardware and software. (his has more power).
mine has a unique range.
his has mechanical reach.
we are waiting for a response from cslab regarding the topic described at the beginning of the topic related to errors in the feed during the thread.
we tried the thread with G76 and G32.
The result is the same.
if you run the thread in a loop, it is not the best, but it is acceptable.
if the cycle is repeated, both empty and with correction on the measurements, the wire is slowly damaged.
as already said, we are waiting for an answer.
I will keep you informed.
-
Hi Daniba73,
Judging by the serious lack of response to these postings I have a feeling that, sadly, you are the only person here that is threading with Mach4. :'(
I look forward to hearing about your latest testing.
Tweakie.
-
Start off topic.
The real rival of Mach4 that blocks sales and development is Mach3 itself.
we face reality.
Mach3, although long-standing, still works quite well, although it is now never weak.
Mach3 has become a free program, given the countless bogus licenses that run on the web.
Users are unlikely to switch to Mach4 for this cause.
in my opinion if they want to stop it, they should remove Mach3 from their site.
Mach4 has if it works perfectly, it would have no equal, I am convinced!
end of topic.
-
for the tests we also tried with a parametric program (made by my friend).
The purpose of this program was to exclude Mach4 for thread calculations.
he only had to carry out the instructions provided by mathematical calculations.
some past emails, cslab told us that the trajectories are calculated by Mach4, CSMIO just needs to synchronize (and here it does it well, because we tried to disturb the rotation of the spindle with a wooden rod while running the wire, and not lost the pace despite revolutions that varied by about 10 or 15 shifts).
nevertheless, if the thread was passed over again, the thread was slowly damaged.
we evaluated the conditions:
the defaut lathe has trapezoidal belts between the engine and gearbox.
the trapeze belts, as is known, have oscillating rotation.
since turns oscillate for that cause, we have deduced that for the calculations a certain number of turns is taken into consideration, and the thread is valid.
the cycle is repeated, and due to oscillation (given by the trapezoid) another rpm value is taken.
by varying the turns the calculations also vary.
and this could be the cause.
ArtSoft and CsLab should communicate well how to solve the problem.
unfortunately now my friend has influence.
as soon as it heals, we run the tests again and insert the images of the results.
I attach the parametric program.
%
O1
(............................................)
(.........INIZIO DATI DA INSERIRE............)
(............................................)
T202 (FILETTATORE, INTERNO o ESTERNO)
G97 S500 M3
G99
G61
(............................................)
#101=10 (POSIZIONAMANTO..Z..)
#102=105 (POSIZIONAMENTO..X..)
#103=100 (DIAMETRO INIZIO FILETTO)
#104=97.4 (DIAMETRO FINE FILETTO)
#105=1 ( 1 FILETTO ESTERNO -1 FILETTO INTERNO )
#106=12 (NUMERO PASSATE)
#107=0.02 (SOVRAMETALLO PER FINITURA SUL DIAMETRO)
#108=1 (PASSATE DI FINITURA. MINIMO 1)
#109=1 ( 0 INCREMENTO RADIALE 1 INCREMENTO X/Z+ -1 INCREMENTO X/Z- )
#110=30 (ANGOLO DI ENTRATA FILETTO)
#111=30 (..Z.. FINALE. METTERE VALORE SENZA SEGNO)
#112=2 (PASSO FILETTO)
(............................................)
(.........FINE DATI DA INSERIRE............)
(............................................)
%
#120=[#103-#104-#107] (METALLO DA ASPORTARE)
#121=[#120/#106] (INCREMENTO IN X)
#121=[#121*#105]
#122=TAN[#110]
#123=[#121/2] (INCREMENTO Z)
#123=[#123*#122] (INCREMENTO Z)
#123=[#123*#109] (INCREMENTO Z)
G0 Z#101 (POSIZIONE INIZIO PROGRAMMA)
G0 X#102 (POSIZIONE INIZIO PROGRAMMA)
#130=#103 (NUOVO VALORE PER SOTTOPROGRAMMA IN X)
#131=#101 (NUOVO VALORE PER SOTTOPROGRAMMA IN Z)
M98 P2 L#106
G0 Z#101 (POSIZIONE INIZIO PROGRAMMA)
G0 X#102 (POSIZIONE INIZIO PROGRAMMA)
#140=[#103-#104] (INCREMENTO Z FINALE)
#140=[#140/2] (INCREMENTO Z FINALE)
#140=[#140*#122] (INCREMENTO Z FINALE)
#140=#101-#140 (INCREMENTO Z FINALE)
M98 P3 L#108
G0 Z#101 (POSIZIONE INIZIO PROGRAMMA)
G0 X#102 (POSIZIONE INIZIO PROGRAMMA)
M30
;
%
O2
#130=[#130-#121]
#131=[#131-#123]
G0 X#130 Z#131
G32 Z-#111 F#112
G0 X#102
G0 Z#101
M99
%
O3
G0 X#104 Z#140
G32 Z-#111 F#112
G0 X#102
G0 Z#101
M99
;
-
daniba,
I will post a few "simple" tests that you need to do. Leaving for a trip very shortly.
I'll post them when I get back in a few days.
Till then,
RICH
-
Thanks for your interest.
I will also run your tests.
although I believe the problem has been identified on the issue of recovering the damaged thread.
example.
suppose we have a G97 S500 M3
due to the oscillation this value oscillates between 500 and 505 rpm.
when the thread cycle starts, Mach4 will draw on one of those values to perform trajectory calculations.
the thread is working properly.
now you have to repeat the cycle to reach the correct size.
start the spindle and repeat threads.
but due to the swing this time it generates a trajectory based on 505 rpm.
inevitably the newly created thread will be damaged.
now it's up to ArtSoft and CsLab to find a solution.
-
We have a Mori at the shop that threads all day every day. Threading is a motion controller dependent function. For Mach, we treat G32 moves (the basis for all threading ops) as a regular feed moves. But we mark them so that the motion controller can sync them with the spindle. There is nothing else Mach can do, at this point, because the motion hardware has to do the real-time stuff.
Steve
-
You need to ask CS Labs how it's motion controller handles varying spindle speed at both index time and during the actual threading. Also find out how current their plugin is with the current version of Mach4.
The above is different than:
CSMIO-ENC from machine start, spindle activation, and Index signal finding it starts to count encoder position, spindle angle, and speed. All the information are transferred by the CAN bus to a CSMIO/IP motion controller, where they are treated by algorithms which task is to accurately and smoothly synchronize move of a Z-axis to a spindle during G32 or M84 command activation. At the moment of threading when the Z axis moves, the CSMIO/IP motion controller sends current axis position to Mach3, so its Z-axis position DRO shows the real position.
RICH
-
Hi,
in this period I am out on business.
as soon as possible I try!
thank you!
-
Hi Rich, I want to ask you a question?
The csmio ip is the one that controls the z axis and synchronizes with the rpm.
But how can I do that synchronization?
I have the csmio ip + csmio enc.
The rpm that the encoder gives me is real, but when doing the threading cycle the tool is placed on me but it does not advance, I have to miss something, because I see that people at least advance.
It would be a great help if you could help me. Thank you.
-
After multiple tests, I found that sync is excellent.
the main problem is that if you have to go beyond the thread to reach the finished size, the previously created thread is damaged because it does not start again in the same place.
-
Hi Daniba.
Could you send me if you do not mind a photo of the configuration of how you did it to get it?
thanks
-
if you tell me which photo you want to see I will.
-
have updated V3.205 plugins
they solved the problem of the mechanical ranges that produced error on the thread pitch.
The thread recovery problem has remained unchanged.
by looping, it completely ruins the previously created thread.
I attach images and video links (I apologize for the low quality of the video, my friend is not practical).
https://drive.google.com/file/d/1O_zBu7s24WxlIVlA4IPZkrSB6AuMQ5In/view?usp=sharing
-
I declare that the mechanical and electrical parts are perfect, so the problem is only software !!.
I haven't used Mach4 or the CS lab but this resembles an issue I had earlier with Mach3 on my lathe. (and mill, btw)
Set a dial indicator to 0.000 at your Z start position. (or where it won't get hit during the program run)
Then run your threading cycle "in air" 2 times (or more).
Verify that it still indicates 0.000 at the end of each cycle.
If it is 0.000, I'm done and sorry that I cannot help.
Russ
-
Are you running on Servo or Stepper motors?
-
we use Delta ASDA B2 servo motors.
in turning it is very precise.
maybe we understand where the problem lies.
as spindle motor we use asynchronous + VFD.
to transfer the motion, between engine and gearbox are trapezoidal belts (original of the lathe).
probably the type of engine / transmission is not suitable.
I say this, because there is an oscillation of the rpm, caused by the trapezoidal belts.
from the various tests, we came to the conclusion that by starting the thread cycle, a certain number of laps is taken to activate synchronism.
this is maintained perfectly even in the presence of speed oscillation.
the problem is created when the cycle must be repeated several times.
precisely due to oscillation, data other than the first cycle is examined, causing damage to the previous thread.
-
Where are you getting the index pulse from?
If from a sensor is it mounted to read from the main spindle?
-
it is mounted on the spindle line, ratio 1: 1 as per cslab instructions.
this lathe is not mine, it belongs to a great friend of mine.
for this I feel a little guilty, for having convinced him to use CSMIO.IP-S and Mach4 paired.
I own a small Optimun TU2807 lathe with the same hardware (smaller in power, given the small size of my lathe).
the only configuration difference is that I have a unique range, transmission motor / spindle shaft via asynchronous pulley / belt pitch 5 HTD.
I have a small mistake in case of wire overhaul, for this reason, we believe that the cause is the oscillation of the spindle turns caused by V-belts.
-
...... we believe that the cause is the oscillation of the spindle turns caused by V-belts.
I don't think that will cause what we see in your video of the subsequent cycle.
The enclosure could possibly win the "5 lbs. of goodies in a 3 lb. bag" award :D
Thank goodness for the 24v noise immunity of the CSLab components ! :) :
Is the encoder 5V ?
You could also thread a new part and set the spring passes to 10 (or more) and watch for any deviations .. which should be clearly evident.
I sincerely hope you find the issue, I'll be curiously watching.
Cheers.
:)
-
we don't know what to think anymore ...
we try to replace trapezoidal pulleys with asynchronous HTD.
then let's see what happens.
thank you all for support.
-
We have a Mori at the shop that threads all day every day. Threading is a motion controller dependent function. For Mach, we treat G32 moves (the basis for all threading ops) as a regular feed moves. But we mark them so that the motion controller can sync them with the spindle. There is nothing else Mach can do, at this point, because the motion hardware has to do the real-time stuff.
Steve
Hi Steve,
Just out of curiosity which motion controller are you using with your Mori and which version / build of Mach4 are you using with it please ?
Tweakie.
-
in this video cslab has shown that the thread with Mach4 works very well.
I must try well to understand where my problem is generated.
-
We have a Mori at the shop that threads all day every day. Threading is a motion controller dependent function. For Mach, we treat G32 moves (the basis for all threading ops) as a regular feed moves. But we mark them so that the motion controller can sync them with the spindle. There is nothing else Mach can do, at this point, because the motion hardware has to do the real-time stuff.
Steve
Hi Steve,
Just out of curiosity which motion controller are you using with your Mori and which version / build of Mach4 are you using with it please ?
Tweakie.
The Mori is using a Vital Systems HiCON controller. I don't know the Mach build but Rob G would know as he is the primary operator of that machine. I doubt the build would matter as threading is more dependent on the motion controller and its' associated plugin than the Mach build. So I can confidently say that ANY Mach build. :)
It is a sweet machine to see in action!
Steve
-
Thanks Steve, I was hopeful that it would not be the most expensive controller but I suppose that quality and support come at a price.
There is so much going on with controllers that 'sort of work' it is nice to know which controller 'does actually work' when it comes to threading. I will just have to start saving my pennies :)
Tweakie.
-
Hi,
We have identified the problems that caused bad synchronization with G76.
I thought it was correct to notify, so if a user has the same problems, he has a solution.
To generate the problems was the VFD.
It generated disturbances on the signals.
To solve this, we physically moved the VFD away from the controller, with separate power supply.
The disturbances have disappeared, consequently the G76 now works correctly.