Advanced Search

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.

Here are the Hal and Ini files

Marcos wrote:

If someone with LCEC + CiA402 hardware would be willing to test the modular stack on real drives, I can prepare:

- Clean HAL example configuration
- Minimal README
- Reproducible test steps
- Fault and homing test scenarios


 

I currently have a Lichuan model OL57E-4A 4-axis drive and a Stepperonline model A6-750EC 750 watt servo drive set up on the workbench for testing, I can connect homing and limit switches without too much trouble.
Both are LCEC + CiA402.
The Lichuan manual is available here:  git.gitcoding.net/nwe/lcec_4x_stepper/src/branch/main/manual
The Stepperonline manual is  here .

I'd be willing to test drive your config. It might be a couple days till I find time.

I would agree with Tom here, that there's something basic wrong with the hal  or ini files.

(my guess would be no position feedback connection from the steppgens)

I think I need to apologise, I'm currently testing a working serial/USB setup.
Not simple IO, 1kHz loop 3-axis stepper real-time control.
But I can't quite believe it yet, still have a lot to test.

I actually wanted to try building something for the RPI serial port, small and cheap, but for development I have it on the PC with USB/serial, and the bloody thing works.

Norbert,
Was the HAL pin for 'manual tool change confirmation dialog' ever implemented ?
I'm in the process of changing from par ports to mesa 7i92 and moving the PC out of the machine cabinet, as such my keyboard hack for a physical button on the control panel to press the 'Enter' key is no longer practical and with the larger amounts of i/p pins on the mesa card I would like to hook the physical button to a mesa gpio i/p pin and use that to clear the gmoccapy tool change dialog popup

now using 2.9.8 latest build