Page 2 sur 3

Re: Next version of JediCut?

Posté : ven. févr. 13, 2009 11:01 am
par HCNC
and total free setting LPT bits (also heating control and motor on/off)!:)

Re: Next version of JediCut?

Posté : ven. févr. 13, 2009 8:04 pm
par Jerome
Zoltan,

I'm sorry, I don't understand... What do you want with" backslash" ?

HCNC,

It's in project but I need time to test Jedicut's controls ;)

Re: Next version of JediCut?

Posté : ven. févr. 13, 2009 8:29 pm
par HCNC
Understanding! Thanks!

Re: Next version of JediCut?

Posté : sam. févr. 14, 2009 8:43 am
par Zoltan
Hi Jerome,

Lost a few steps when change the cut direction (screw and nut error)... I think it's the backslash .
(see Mach3 settings for example)

By, Zoltan

Re: Next version of JediCut?

Posté : mar. févr. 17, 2009 3:32 pm
par HCNC
Dear Jerome!

Have you thought of using a trapezoid movement profile in speeding up and slowing down the motors ? This technique could be useful in increasing stepper motor speeds! At present, because the lack of this movement profile the stepper motors can only be used in the low speed range.The program can generate higher frequency output signals. If you would use this profile only in rapid traverse mode (G00, in CNC language) the quality of of the cut would remain the same but the whole process would speed up. Of course, it would be nice if the starting and stopping speed could be set up by the user of the software, and the acceleration time deceleration also at starting and stopping. As I can see the speeds (cutting speed and rapid traverse speed) set up of the incoming pulses by dividing them with two fixed value. If you need any help ask bravely anything from me.

Best regards HCNC.


Cher Jérôme!

Avez-vous pensé de l'utilisation d'une plus rapide, rampe "courbe" est d'accélérer et de ralentir? Cette technique pourrait être très fortement augmenté par une accélération du moteur à être utilisé! À l'heure actuelle, par conséquent, le stepper n'est pas seulement le Ramp Start-Stop plage de vitesse peut être utilisée, même si le programme est capable de beaucoup plus élevés (ce qui ne devrait augmenter la fréquence de générateur de signal). Si vous utilisez uniquement l'occasion de la rampe est plus rapide, vous ne pouvez pas changer la qualité de la coupe, mais l'ensemble du processus est l'accélération.
Bien sûr, il serait bon que le premier et le dernier de vitesse au sol, et le temps de démarrage pour l'utilisateur de mettre leur propre moteur. Comme vous pouvez le voir la vitesse (la vitesse de coupe et de la vitesse) des impulsions en divisant l'ensemble en deux fixes. La rampe, le plus rapide évolution dans le temps. Il serait une valeur initiale (la valeur de la scission de la vitesse de coupe, ce sera mai), puis une période de réglage du temps pour parvenir à la division de la valeur à grande vitesse. En revanche, démarrer le moteur et l'accélération de retour réglementer, il serait break. Bien entendu, cette approche ne conduit pas à des accélérations et de freinage, mais une valeur de plus de la dur fixe de démarrage et de stop. Bien entendu, le programme doit être préparé pour cela, parce que les freins devraient être reconnus à l'avance, et le temps de commencer à diviser la valeur de l'amendement.

With Google translater...:)

Re: Next version of JediCut?

Posté : mer. févr. 18, 2009 9:55 am
par HCNC
Dear Jerome,


Engine speed might be dramatically increased under quickrun with this
technique. Currently there's no RAMP therefore step motors can be used only
in the range of Start-Stop velocity; however the program code is able to
work in even faster speed. For this the generator frequency should be
increased only.


In case you would use RAMP under quickrun only, the quality of cut would not
change but the whole running would speed up.


Certainly, Would be great if the user could adjust the initial and ending
velocity as well as the running-up time to his own engine. As I see the two
speed (cutting and quickrun velocity) are set by the division of two fixed
incoming pulses. The RAMP would change the partition of the quickrun
(timebase) in the gear of time.


After the initial value (that could be the divided value of the cut
velocity); the partition would reach the quickrun value in reasonable time.


By this, the engine would start in quick time and stop with reverse
controlled break. Of course this solution would not result in linear
acceleration and braking but would be better than fix, hard starting and
stop.


Certainly the program must be prepared for this because the braking must be
identified and start the change of the partition value, in time.

Re: Next version of JediCut?

Posté : sam. mars 21, 2009 8:23 am
par HCNC
Hello Jerome!

By what time next versio?

Re: Next version of JediCut?

Posté : dim. mars 22, 2009 8:07 pm
par Jerome
Hi,

Soon. I'm running tests on the new version.

Re: Next version of JediCut?

Posté : lun. févr. 01, 2010 8:06 am
par HCNC
Hello Jerome!

Which version DXF compadtible of new JediCut (V2.2.2)? R12, R11, ...?
This is usable fuselage cutting?
Thx!

Istvan

Re: Next version of JediCut?

Posté : lun. févr. 01, 2010 7:29 pm
par Jerome
Hello,

R12, but it's a beta functionality, and it seems to be a problem on the new version.

You can cut fuselage but if you have the profiles, like wings.