Advanced Search

No need, it should work as is.
Do you have enable wired to your drives?

I use Raspery on Pi5, there are no problems, it starts automatically without a password when the first power comes on. While the CNC is running and processing materials, a password login screen appears occasionally, but the CNC does not stop and continues to work. What causes this encrypted login screen to appear?

You could try using the 'hal_input' component and see what keys your keyboard offers. These can then be connected in hal to the .increse/.decrease pins of gmoccapy.
linuxcnc.org/docs/html/gui/gmoccapy.html#_hal_pins

example:

1. open a terminal and type:
2. find your keyboard in the output
example: 'Bus 003 Device 002: ID 17ef:608c Lenovo Lenovo Calliope USB Keyboard'

3. Add this to the [HAL] section of your ini file using one of the words from the keyboard identification from above to identify the device (for our example we use 'Keyboard')

4. Start your config, enter the settings page and click on the 'Halshow' button in the lower right corner

5. Navigate to pins/input/0/ and check if any function keys have been recognized:

 

6. In our example there are some function keys we can use (eg 'input.0.key-volumeup', 'input.0.key-volumedown')

7. Connect these pins to the relevant gmoccapy halpins in the POSTGUI_HALFILE (eg to control the linear jog velocity):

possible pins can also be found in pins/gmoccpy.
 

linuxcnc.org/docs/html/man/man1/hal_input.1.html

tommylight wrote:

Connect to input on BOB, then in hal connect that input to joint.N.amp-fault.
Or in your case if you have them with e-stop, in hal connect to estop-ext.

Apart from the cable connection, do I have to modify anything in my HAL file so that the alarm works with the emergency stop?

The problem I have is that I don't know how to connect the cables from the driver to the bob. I also don't know if alarm+ needs voltage.....

Somewhere here I read something about the pins for encoders, but I can't find it again. I think there was talk of only one possible encoder. Either for the spindle signal, or MPG, which would be a shame if you have to decide on one. I saw the pinmapping in this post.

forum.linuxcnc.org/18-computer/44828-rem...rd?start=1750#303975
 

Yes, axis supports 1-0 for feed overrides. Sadly it doesn't work on gmoccapy. I can see in some videos over youtube that there used to be sliders at sometime. As a beginner in CNC the sliders and shortcuts are very very useful for me

I'm glad that was an easy fix.

In Axis, number keys from ` to 0 (yes the first is the tidle key under ESC and to the left of 1) are feed overrides so you can press them at any time to set the feed speed, meaning the ` is 0 feed rate so the machine will not move, 1 is 10%, 2 is 20% and so on.
No idea if that works for GmoccaPy.

I am using Axis for my lathe currently. I was recently looking at the gmoccapy GUI in sim mode, everything is much better here. But one thing is keeping me off from using it is the sliders for the Rapid/feed/spindle/jog override. In axis, one can just move the sliders from 0 to 100 in half a second, but you have to press the '+' or '-" to adjust them. Are there any shortcuts for this or any way to get adjustable sliders in gmoccapy like axisui? Thanks in advance.

One way to check the index/encoder  is to:

1. Disable the drive so the spindle can be turned by hand

2. Verify that the spindle position from the encoder increases by 1.00 for each forward turn.

3. With halcmd (in a terminal) set the index enable:

halcmd sets spindle-index-enable true

now, when you rotate the spindle. at the index position:

the spindle position should be reset to 0

spindle-index-enable should go false

You can watch the spindle position (spindle.0.revs) and spindle-index-enable
with halshows watch tab






 

position feedback must be unconnected in spindle mode

meister wrote:

i knew you were working on something modular but you exceeded all my expectations, respect !

WOW !!!!!

Thanks! It really did turn out to be more complicated than I first imagined (the more I thought about using the colorlight modules the less I liked the idea, so in the end I just decided to go for FPGA onboard).

I'm also not fully certain if the non-opto-isolated encoder and stepdir modules will be a good idea- at least the motor drives I'm using all have opto-isolated stepdir inputs, and the PC side is isolated via Ethernet- so should be good enough for my uses.

Time will also tell if 12 bits per module is enough or too limiting. Probably the only use case I can see is something that needs a lot of IOs wired directly- the shift-register based module should be enough for general purpose CNC use (buttons, endstops, relays etc).

Cant do this anymore bye all wrote:

Looks good. Lots of hard work. Lots of thought gone into it.


Generally when I've been designing my boards I've followed the mesa example where all the signals from the FPGA that will be controller something go through a FET bus switch with a pullup resistor to 5v on the "world side"(I'm a cruddy old guy lol, I like 5v). Gives you bi directional voltage translation, and works fine even with the 2.5MHz SmartSerial signals (when I use mesa firmware tho my design also can run rio with no issues). To drive outputs I add a buffer or just connect directly to a simple Parallel Port breakout board.

Have you thought about screw terminals for the outputs ?
With regards to the differential outputs for the stepper drivers, it would take some serious noise to have any affect when driving an opto. I've used plain old 74 series 540/541 powered by 5 volts with no issues for years, plenty of drive there. And generally the cable length isn't all that great from between the step\dir source & destination.

Tommy linked a video to a guy that experiments with noise & shielded cables, very interesting.

For 5v to 3.3v translation 74lvc is a good candidate.

Thanks for the suggestions. The digital input module has spring-type wiring terminals (though now when I looked at it, my choice of two row 3.5mm pitch may have gone a bit too tiny). Regarding the stepdir/encoder- I really don't like how messy does the differential signal wiring becomes, so I'll be trying out the off-the-shelf cables + specific breakout boards (for encoder, for particular servo drives). Of course, there is also the generic RJ45->wiring terminal breakout for those unforseen circumstances.

 

Hi Russell,
good idea, thank you very much,
I would prefer riocore
it is no longer worth doing new things with the old version
Cheers.
Olli