Advanced Search

newbynobi wrote:

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.

Hmm this is not natively supported by the GtkProgressbar, but could be done with a GtkOverlay:this



But automatic text coloring to increase the contrast is not possible like this i.sstatic.net/PJJqs.png

I liked the decent progressbar better and also the text was better readable. Furthermore there are now to many colors for the bars.

chrischan wrote:

I thought that a foldable ferrit and just passing through would be enough.

That should also help a bit, might be just enough in your case.

Oh okay, then I have to check for cable length. I thought that a foldable ferrit and just passing through would be enough.

So I will organise a ring.

Hallo zusammen,
ich plane, in meiner LinuxCNC-Umgebung zwei Taster einzubauen:
* Taster 1: Y-Achse mit 50 von 100 positiver Geschwindigkeit
* Taster 2: Y-Achse mit 100 von 100 positiver Geschwindigkeit

Ich frage mich, ob das umsetzbar ist und wie viel Aufwand das bedeutet.Bestellt habe ich diese Taster: www.amazon.de/dp/B08B5YC29H

Mein aktuelles Setup:
* LinuxCNC Version: 2.8 (soweit ich mich erinnere)
* Hardware: Mesa 7I95 Karte

Sobald ich wieder an der Anlage bin, kann ich die HAL- und INI-Dateien hier posten.

Außerdem interessiert mich: Was passiert, wenn ich die Taster in die Konfiguration integriere, sie aber (noch) nicht angeschlossen sind? Gibt es dann Probleme, oder bleibt das System funktionsfähig?

Vielen Dank im Voraus für Eure Unterstützung!

Viele Grüße,
Mücke

Great thank you!

I go the same error "..a-pos-_fb..." so i followed your advice and changed that to "aa-pos_fb" and got the program to open. Hooray!

naturally i powered the machine on with the touch button and went to press the estop wired to the mesa to test and the external estop, and it did nothing on the screen not stopped the machine. 

I seem to have mixed up some motor assignments so ill need to now find a way to reassign motors without going back through the pnconf setup again, any suggestions?

chrischan wrote:

Am I right if every wire (UVW) needs an own ferrit?

No, one ferrite, all 3 motor wires looped through it at least once, not just passing through.

are you just trying to use 2 tools on one station without operating the turret ?
?

Tested the SSR today and some of you already mentioned it: no changes in mouse behaviour.

Next will be the ferrite beads. I checked the VFD wiring and there is enough space to install them.
A line filter is already installed inside the VFD housing.

Am I right if every wire (UVW) needs an own ferrit?

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.