Advanced Search

Is there any documentation which is explaining all type of connections?
Like e.g.:
encoding - The position encoding. ( Default = ’gray’)

1) gray - ... (needed pins in the component, scheme, a picture how it looks, hal file example maybe)
2) binary - ...(needed pins in the component, scheme, a picture how it looks, hal file example maybe)
3) bcd - ...(needed pins in the component, scheme, a picture how it looks, hal file example maybe)
4) index - ...(needed pins in the component, scheme, a picture how it looks, hal file example maybe)
5) edge - ...(needed pins in the component, scheme, a picture how it looks, hal file example maybe)
6) counts - ...(needed pins in the component, scheme, a picture how it looks, hal file example maybe)
7) single - ...(needed pins in the component, scheme, a picture how it looks, hal file example maybe)
8) Saw somewhere positioning by an encoder feedback - (needed pins in the component, scheme, a picture how it looks, hal file example maybe)

Driver control mode:

1) step/dir (Stepper/servo motor - needed pins in the component, scheme, a picture how it looks, hal file example maybe)
2) analog (Servo morotr/ VFD - needed pins in the component, scheme, a picture how it looks, hal file example maybe)
3) Forward/Reverse - 2 pin control (DC/ AC motors - needed pins in the component, scheme, a picture how it looks, hal file example maybe)

I'm under the impression that the encoders are 1 million counts per rev. I did a crude test where I rotated the pully associated with the motor one full turn as marked by a sharpie line on the face of the pulley. Seemed to deliver around 2 million raw counts, and the pulley appears like it could be 1:2 ratio. 



I also observed 4 cycles of the commutation output from the HAL Fanuc Encoder pin for one rotation (if I remember correctly!). 

These computer-side details can be adjusted as I setup the system. Now I need to figure out what extra hardware I need to talk to 4 of these at once, and also how to output either commutation to the Allen-Bradley Ultra-3000 drives or incremental encoder signals. I'm fully out of inputs and outputs on my 7i76e used on the machine so I will need to get some expansion hardware. 

Expansion needs: 
-4x serial ports (maybe just 3 if I can also use the one in the 7i76e, but Mesa seems to sell them in breakout boards of 4 or 6). 
-8 or more outputs to communicate encoder or commutation information to the Ultra3000 (still figuring out what the drives will need) 

Wondering what the most cost effective Mesa solution would be to add onto my system. 

Or maybe someone knows if there is there setup that does not require sending encoder or commutation information to the Ultra3000s. Can't seem to find whether or not these drives can be run 'open-loop' or/ with feedback only being taken care of on the LCNC side (doubtful?). 
 

It looks great. I can't wait to try it out!

thanks for info i will try it now . nice work !

I don't think you''ll get much more speed out of the python interface. There is also 'linuxcncrsh' which is written in c++, which might be worth a try (although as such also non-realtime) You can also connect to it over localhost:
linuxcnc.org/docs/html/man/man1/linuxcncrsh.1.html

I vote for 4:12 min as time format or 1:36 h if time is over one hour

As for the progress bar, is it possible to put the elapsed Time or percentage within the bar?
I mean something like the number in the spindle feedback bar.

Norbert

@Hellvetica,

It's what Arciera mentioned before. External offsets could do what you want.
Mdi is just far to slow.

Using a custom trajectory planner:
I can imagine adding gcode lines at runtime including blends trough hal pins at runtime.
And even cancelling existing paht moves, and update them including blend to new target position.



 

As I understand it there is one linear and four rotary axes which is not one of the traditional 5axis kinematics (ie 3 linear and 2 rotary).

Ah yes the editor. Truly you have come of age and walked the path of darkness

I would just watch the encoder velocity in halshow

I edited my original post to include changing the display protocol from Wayland to X11. Comments by rodw and cornholio were based on the terrible jitter that Wayland induces as shown above.

Note that Kunena has the worst forum editor I've ever used, and it was quite a job to edit those posts and restore the formatting. I wonder if forum posting would increase with forum software that was more user friendly.