Hello Guest it is April 25, 2024, 05:39:27 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - daniba73

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
131
CS-Lab / Re: CSMIO/IP-A Mach4 lathe retrofit
« on: April 01, 2020, 10:38:33 AM »
Hello.
first of all IP A supports the thread ?? you asked CsLab ??
there are functions that work on the IP S, while on the IP A they do not work.
do you use mechanical ranges?
the impulses are set right to 10000 ?? (2500 * 4).
what kind of motor do you use for the spindle ??

132
CS-Lab / Re: CSMIO/IP-A Mach4 lathe retrofit
« on: March 25, 2020, 03:55:40 AM »
I with CSMIO IP S can thread.
synchronism is excellent.
the only problem (which is very important) is that if I inevitably have to resume the threading cycle to reach the necessary dimensions, there is the risk of throwing the piece away because it does not always start from the same point, as a result I spoil the thread previously created.
I have already reported this problem several times to cslab, but they reply that their controller is only responsible for synchronism, the route calculations there do Mach4.
what kind of spindle do you use?

I add a note
on my lathe, I have a single interval.
but a friend of mine who has mechanical intervals, despite the fact that the table has been correctly compiled, (therefore the scheduled shifts correspond to the real for each interval)
the thread pitch is totally wrong !!!
to do it well, he must deliberately enter an incorrect step that he finds (now I don't remember if he multiplies or divides) using the ratio value for the step.
is something that absolutely must be solved !!

133
Hi,
in this period I am out on business.
as soon as possible I try!
thank you!

134
Hi,
in this period I am out on business.
as soon as possible I try!
thank you!

135
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.

136
hi, I immediately ask the question.
I would like to impose an insurmountable limit in Rapid Override in Mach4.
I will explain.
with CSMIO I have the possibility to constrain both Feed Override and Rapid Override with a single potentiometer, and this is very convenient!
the problem arises when a new gcode written on the machine occurs.
to maintain the correct feed you must keep the value of 100%.
the problem is that even the rapids are at 100% of the value.
I would like to impose an insurmountable limit on the Rapid Override type 5% 25% 50% 75% 100% via panel buttons.

this however must not affect the Feed.
hypothesis.
I press button at 25%
keeping the potentiometer at 100% to keep the Feed programmed, the rapids must not go beyond its 25% speed.
it's possible to do it ??

137
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
;

138
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.

139
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.

140
Mach4 General Discussion / Re: MACH 4 bugs when cutting?
« on: January 23, 2020, 02:32:30 AM »
set the look ahead with a value of 200.
you should solve.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »