Advanced Search

This issue originated from LinuxCNC and occurred nine times within ~30 minutes.

not sooo bad

not knowing how you print your message but how much of your main loop taken up by printing your message? It might not be as bad as you think.
Maybe an exercise for halstreamer?

Ja der alte Motor ist bereits Entsorgt. Ich war Überrascht über seine Leichtgängigkeit und seinem geringen Gewicht. Für das Alter. Hab ich mir anders vorgestellt. Ja der neue Servo hat selbstverständlich einen Encoder. Ich werde mal sehen was das Umkehrspiel sagt. Aber Früher hat es ja auch funktioniert. Wieso jetzt nicht mehr? Für gröbere Arbeiten sollte es nach wie vor reichen.

The" bitslice" hal component is one way.

 

Is there a way to extract a specific bit from a hexadecimal value? The VFD I'm using indicates the state with a 16-bit hexadecimal value, and therefore I need to extract that bit to use it within my configuration.

So we have wound up with a simple little 3 axis cartesian robot. Robot basically has a spindle taper and air powered gripper, and then hands off to a switcher arm that will be moved by the little robot with a roller cam. 





I will probably build this in april, then we can see if it can live inside the master linuxcnc or needs a separate controller.

So the run down:

- X, Y, Z linear motion.
- gripper air cylinder.

1: Robot on its own goes to grab the next tool needed by the machine, and places it in the arm SLOT A
2: M6 Tx called
3: Robot uses cam to move arm out into position. Door opens on the same linkage (we could also do this with air)
4: Machine moves to tool change arm and places the tool in SLOT B
5: Then it grabs the tool in SLOT A and moves away from the arm

Basically the main control sees the atc as a stationary rack type with only 2 tools

6: The arm retracts in and door closes
7: Machine resumes cutting
8: The robot takes the tool from SLOT B and puts it back in the right pocket
9: Robot grabs the next tool in the program and we repeat everything again

Make sense?

The new version of qtdragon at github.com/persei802/QtDragon_hd has the ability to semi-automate tool measurements. I'm open to suggestions for improvements.
Jim

setp [HMOT](CARD0).stepgen.00.control-type 0

Is wrong, it should be:

setp [HMOT](CARD0).stepgen.00.control-type 1

(for all joints)

 

clem wrote:

The are not Inovance, they are Jssmotors, as you can see in this link:

www.jssmotor.com/servo-system

You are absolutely right.  Earlier post edited - thanks.

Its about 0.17mm along the whole Z axis. Mostly near the chuck as always. Could you perhaps share a bit of what you had done? Attaching the picture of my bed wear. 

Pretty sure that if  you have combined home/limit switches you will need a
HOME setting that's away from the switch actuation point or the ON LIMIT
errors are guaranteed.
 

OK, so the only solution seems to be the timedelay/oneshot version, where it would command the tool change always in the same direction (not sure if ABS component helps), does need a bit of hal wizardry, but i am out of ideas for now on how exactly to achieve that.

From a very quick and short glance, what is this
setp axis.x.jog-accel-fraction 0.3
doing inside the hal file?
Probably not the exact issue, as i still think there is something terribly wrong with the wiring, but the symptoms are not that clear cut to be able to pinpoint.
Check with scope how the signal between signal pins on Mesa and drive look in relation to gnd and machine/box ground look, might be ground interference at 50 or 60Hz causing it.

answering my own question, the pin is gmoccapy.toolchange-confirm

I connected this in postguihal as below -

net tool-change-button => hm2_7i92,0,gpio.028.in_not <= gmoccapy.toolchange-confirm

Hier kann ich eine Antwort schreiben, in den anderen beiden Themen jedoch nicht. Das ist schon sehr merkwürdig.