Advanced Search

Thanks for the feedback. Just to clarify an important point that I may not have emphasized clearly:

All components in the current tests run in the same servo-thread at 1 kHz, with a fixed execution order using addf. For example:

safety → pds_manager → procedure (UT) → controlword composer → driver interface

Because of this, execution is deterministic. In HAL this effectively becomes a sequential call chain within the same realtime cycle.

Also, there is only one writer for the final 6040 controlword, produced by the controlword composer, which avoids the typical “multiple writers” problem that often causes ambiguous state transitions.

In HAL, race conditions are caused by multiple threads or multiple writers, not by the number of components.

Regarding gantry and coupling: I agree that final squaring and coordinated homing logic belongs in the motion/kinematics layer. If a coupler is introduced on the HAL side it would only serve a limited purpose — handling safe decouple/recouple situations when the drive performs internal motion (for example CiA402 homing) to avoid command/feedback jumps. It would not replace motion’s gantry or homing logic.

Interestingly, the recent HOME_ABSOLUTE_ENCODER fix in motion (PR #3774) also highlights a similar concern about maintaining internal consistency when offsets are applied during homing. In that patch the motion code re-normalizes pos_cmd, pos_fb, free_tp.curr_pos, and motor_offset to avoid accumulated offsets during re-homing. Conceptually this looks similar to a recoupling step inside the motion layer to keep controller and physical states aligned.

The goal here is not to duplicate motion functionality, but simply to keep CiA402 semantics independent from the transport layer (LCEC/EtherCAT) while maintaining a deterministic controlword path.

I can make a (7I92) bitfile but are you sure 7I92 bitfiles will work on that card?

OK das ist forum fehller, aber es gibt kein info was hat shief geganen.
Had die thema im ein anderen sub forum geschickt, versuch noh mal bitte.

forum.linuxcnc.org/additive-manufacturin...drive-gesucht#343661

ClarkSavage wrote:

Funny, the homing was INVERTED in Stepconf, but now is not in Pnnconf. Also the latest Pnnconf instructions do not match the Pnnconf I see on my machine. ????? documentation must be lagging I guess, realize everybody is busy and this is a free program......

 

Parallel port requires pulling inputs down to trigger,
Mesa can have inputs set for pull down or pull up, in hal
Mesa can use all pins as inputs or as outputs, in any combination, and they are much, much faster than parallel port, so it is impossible to have all possible combinations in a wizard.

Ok, changed all in_out to in and the axes and everything stays enabled - I can jog them. They go in the right direction.

Since I have changed all the limit settings will revisit that later. Many thanks. Your in the run.

Now I need to play with getting my homing back to normal and get the axes unlimited and start uncommenting other stuff too.

Funny, the homing was INVERTED in Stepconf, but now is not in Pnnconf. Also the latest Pnnconf instructions do not match the Pnnconf I see on my machine. ????? documentation must be lagging I guess, realize everybody is busy and this is a free program......

Thanks again.

Thanks again, will report back once I can settle down and get this part straightened out. 

 

kcjengr.github.io/probe_basic/update_notes_stable.html

follow the docs for sa new installation and machine configuration setup. the instructions are there to setup as is needed.

I start with a pyvcp panel...
Drive fwd 1 station button calls in section in my comp
Set tool 1 button calls m61q1

Then i add buttons tool1 tool2.... tool6 to call m6 t1....t6

If i hit drive fwd 1 station it rotates exact 1 station fwd. goes then backward and reduce pwm to get it locked against the pawl.

Now i check temperature ever 15 minutes of driver and dc motor.

Next step is calculating the distance from actual tool position to taeget tool position.. like from tool 1 to tool 6... or from tool 6 to tool 3... handling the rollover would be interesting... we will see in the next days.

If this done is the last step the movement... with the calculated distance on position to go forward i can multiplie with the forwardtime from position to position.. the locking part is not so sensitive.

So we will see... toolchanger without feedback... very oldschool... complete openloop.

Ok those work properly (step generator action is correct)
I suspect the problem is with your jogging setup.

( Which I cannot check unless you include the missing custom.hal
and custom_postgui.hal files )

Well the first thing is that all home switches are inverted...

The need to be false (dim red) when not activated and Yellow when activated.

(whoever chose those colors should be punished somehow...)
 

Yes, I am just confusing myself now.

Yes, looked at Halshow - never done that before so I read a little and then picked what I thought would give the best info.

So, I re-enabled the Y & Z both home limits. All home switches active. I made sure for each test I over road the limits and enable/active Axis display before moving any switch and I got the following. Screenshot is ENABLED base Halshow.

 

Then I methodically tripped switches + and recorded what happened.

For the limit switches at both ends of each axis:

• joint.0.home-sw-in [my 7i92 X] yellow turns red when either switch tripped, then back to yellow on release
• joint.1.home-sw-in [my 7i92 Y] yellow turns red when either switch tripped, then back to yellow on release
• joint.2.home-sw-in [my 7i92 Z] yellow turns red when either switch tripped, then back to yellow on release

Charge Pump:

• charge-pump.enable yellow
• charge-pump.out                   blinking yellow / red
• hm2_7i92.9.gpio.005.in         blinking yellow / red
• hm2_7i92.9.gpio.005.in_not  blinking yellow / red opposite charge-pump.out
• hm2_7i92.9.gpio.005.out       blinking yellow / red opposite charge-pump.out

probe:

• hm2_7i92.9.gpio.016.in             red turns yellow when probe tripped
• hm2_7i92.9.gpio.016.in_not      yellow turns red when probe tripped
• motion.probe-input                    yellow turns red when probe tripped
• probe-in                                     yellow turns red when probe tripped

ESTOP

• hm2.7i92.0.gpio.003.in            red not change when my ESTOP button active, but changes color when axis display button pushed
• hm2.7i92.0.gpio.003.out          yellow not change when my ESTOP button active, but changes color when axis display button pushed
• hm2.7i92.0.gpio.003.in_not     yellow not change when my ESTOP button active, but changes color when axis display button pushed

If you can provide a few hints, I will check and report on other pins. Appears that ALL axis are enabling as long as I over ride limits, and all limit switches are fine if the color should be yellow when the machine is active.

Again, 7i92 connected with short parallel cord directly to mx3660. All limits and ESTOP run through the mx3660 and then would report back to the 7i92.

Appreciate the input. I now have a few things to learn and can see how Halshow sort of works so will check what I have which isn't much - enable, limit switches, Z probe only, external ESTOP.

Finally, I looked everything over for type mistakes but I am kinda deer in the headlights at this time so ask if you think something does not look right.

Here they are

Ich weiß, dass du gut Deutsch lesen kannst. Wenn du Deutsch sprechen möchtest, bist du immer herzlich eingeladen. Dann können wir auch mein Projekt anschauen und weiterentwickeln. :-)Ich kann nur mit einem Übersetzer Englisch, was für mich aber in Ordnung ist.Da du Deutsch lesen kannst, antworte ich auf Deutsch, wenn das für dich in Ordnung ist. Ja, ich finde es auch merkwürdig.Screenshots habe ich im Beitrag davor angehängt, aus beiden Themen, auf die ich nicht antworten kann.Es erscheint auch keine richtige Fehlermeldung, nur der Hinweis, dass: 

Can you post your current hal/ini files that exhibit that behaviour?

Still sounds like a basic hal file issue

I got it working with help of a coder brother and vscode agent by editing mwinterm 's homing files. There were several problems at start which caused inaccuracies in both encoder latched position and home position calculation but now it looks to be accurate. I uploaded quick video of the startup and homing if anyone is interested: www.youtube.com/shorts/St_XhQs68xQ . I also added some nice features;
-the machine offsets are stored within every 2 seconds and those offsets are used as machine offsets at startup before homing, so its kinda like absolute encoders but of course need to be homed to verify position
-custom .py -file checks soft limits before homing and aborts if current position is too close to limit
-also managed to remove homing final move, so minimal amount of movements in homing.

I'm considering if I should share the changed files or not, they are so machine specific. Maybe later when I find out if it's reliable and safe.

Regards
Ossi