Advanced Search

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. 

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

No because i have no feedback! Its only a dc motor and a disc that rotats in one direction and if you drive backward it looks against a pawl.

Here the mechanism

 


The dc motor drives a planetary gear.. the gear drives a wormgear.. the wormgear rotate the disc where the tools are mounted.


do you have a better solution without any feedback?
its not a issue to drive it to tool one and set it as tool 1.

i had years before mounted a stepper and done it with O Codes.. but the dc motor which was original used is bettee because it hold against the pawl. With stepper there is small small movement on the tool because its not holded against the pawl like the dc motor it does.

 

dmesg_new looks better.
However, your vid and pid are incorrect.
They are from Stepperonline A6.
You must enter those from your servos.
vid according to manufacturer xml: 00000eff
pid: 0d3e0001 (not sure)

Note:
please use: dmesg | grep ethercat as root
sudo su
password
dmesg | grep ethercat
that's conspicuous
EtherCAT ERROR 0-3: AL status message 0x001A: "Synchronization error".

Are you using the "carousel" component, or any other, or python remap for the tool changer?

Today morning still did not work for me, now evening and it works with Dark Reader active, so try again and let us know if it works.
-
The forum server is being backed up and upgraded, but for now there are no issues i can see.

set the HOME_search/latch/final velocities to something really, really slow, that way you can see what part of the sequence is causing the issue while homing.