Advanced Search

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

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

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. 

Set velocities low – less than half of previous values – no luck - started “playing” again changing other items as it appeared to me that some thing was interfering with the switch signals.

 had to back off the ballscrew for the Y axis by hand each time as it would hit the limit switch and lock right there. No over ride limits would allow me to jog it away, but that does work for the X and Z - can jog them away after over ride limits.

So tried commenting out stuff just to find what was interfering and - in HAL did the following:

1. commented out ESTOP would not allow me to enable the machine even though the ESTOP position does nothing when tripped to the AXIS display
2. commented out probe lines but did not make a difference so re-enabled
3. commented out coolant - made no difference but I do not have coolant so left commented out

THIS DID make a difference:   left X active, commented out Y & Z, then got LIMITED success:         # --- BOTH-HOME-X ---
         net both-home-x <= hm2_7i92.0.gpio.013.in_not         # --- MAX-HOME-Y ---
         # net max-home-y <= hm2_7i92.0.gpio.014.in_not        # --- BOTH-HOME-Z ---
        # net both-home-z <= hm2_7i92.0.gpio.015.in_notthis did get me an X axis home, with to limit switch then return, limit return latch and then backed off to ZERO and DRO displayed homed - but then immediately after homing gave me an “joint 0 on limit switch error”can someone tell me – I picked “machine actual” in Pnnconf – noticed on the DRO so wondering should I have picked relative which was in the drop down? Image attached after X homed. Reaching for straws I think but I have changed just about everything I can think of as of this point. I leave notes in the files as I change so I can put them back as they were upon changes.
 
 
 

 

 

www.youtube.com/shorts/y8dZws3POOs

Unfortunately, the test quickly shows why it is not a good idea to do something like this:
This is why USB is not suitable for real-time applications, as there is no guarantee that all data will be available within a certain time frame.

But my actual goal is to run the whole thing on the Raspberry via serial port, using RS422.