Advanced Search

Hello  andypugh 

How did you create that table for letting user to input that bending data ?
And how would linuxcnc interact with that data ?
I make a project with the same logic as you,making a tabel for inputting bending data,then i will convert them to Gcode and send to Linuxcnc
but dont know how to create the table for inputting data
Thanks so much
 

AXIS also takes a long time to open it, plus (AXIS, stop) is the same (BUG?), tklinuxcnc response is positive, whether it is loading G-CODE or artifact coordinate offset, but it only has 3 axes.

@meister Here is a python version of spiflash.sh that works on either the rpi4 or rpi5, except the resetting the target afterwards isn't quite working.

github.com/digiexchris/6x11-sg-grinder-l...reconfig/spiflash.py

Unloading and reloading the spi modules on the pi5 image doesn't bring /dev/spidev0,0 device back again on the pi5, so I removed that, and am just power cycling the board to reset the fpga after flashing (sudo halt, wait for it to stop, power cycle). Also it's not possible to manually toggle the state of gpio 7, becaues it's controlled by the spidev0,1 automatically. Is that why you unload and load the spi modules again on the 4, to allow you to manually control the flash chip select pin? It seems that the only thing needed for flashrom to work is just pulling the reset pin low. Not sure how to reset afterwards though. I wonder if I need to set active-low instead, and set it high to reset?

I think on a new version of the board I'm going to put a reset button to interrupt the power to the board in order to manually reset it, and perhaps put a dip switch to set it into flash mode.

Turned mill on today and now it will both jog and enter from the keyboard.
My lack of understanding may have got things wrong.

The problem tracked down to selecting Keyboard Shortcuts on the Systems Page.
If left unchecked, jog and MDI work as they should.

Keep well,
John.

Usually when you have issues as you describe, one side is travelling the wrong way during homing.
Changing the sign on the homing velocities to negative (or posiitve) usually fixes this. Probably latch velocity.
Also slowing the homing velocities right down helps you to see what is going on.

I think so.
Is there anything suspicuous?

Comments.
appTimePeriod must match the SERVO_CYCLE setting in the ini file. If you go for a SERVO_CYCLE of 2ms, change appTimePeriod to 2000000 as well.
The dcConf line says the Ethercat device is running its own loop at 1 ms, synchronized by ethercat"s own internal clock. Sync0Shift says when, inside that 1 ms, the sync event takes place. 1000000 means right at the end of that 1 ms.

Did you see this:
linuxcnc.org/docs/devel/html/gui/qtvcp.h..._sheet_custom_screen
Panels are mostly the same process.

Chris

Yes, poor placemnet and lack of ventilation will casue the  driver to overheat.
Here is a drawing from Lam Technologies
 
Drives at the top of the enclosure with fan above it.

and a real install of the same drivers.
 

Could be the gcode text preview. The high lighting can be cpu intensive.
Could you post a sample large file that shows the problem?

Our image on the downloads page is already pre-shrunk, just like a well fitting pair of jeans
It does make a big difference in the image size

Remember the Linuxcnc RPi images are not meant to be the same as the Official RPi images. They are not to be used as a "daily driver OS", they are solely implemented to drive a cnc machine, and if you are inclined to do some Linuxcnc development.

menu-config will do most of the same stuff as the RPi utils except for setting up the various hardware related stuff. Enabling the various hardware overlays is done by config.txt, which is really really simple as it is very well documented within the file.

There really should be a "sticky" concerning the configuring of these images, without the need to add any RPi tools. And reminding users that the images are NOT related to other RPi OS's/images and such.

I guess there's a lot of people that don't use Linux as a daily driver.

dd works fine on Linux for writing the images, or if you like the GUI route Ubuntu based distro have USB image writer which works fine every time.

Another thing I've noticed, which boils down to understanding things. The Linuxcnc images for the RPi are not related to the Official Raspberry Pi images and are not meant to be used as a "daily driver" OS, they are solely for running a CNC machine and maybe for those that want or need to building Linuxcnc.

So to use these images without any issues, don't assume that they have or need the same tools that the images from the Raspberry Pi foundation.

For reference this is the tool I've used for archiving images (one caveat I'm not a windows or mac user, I'm soley a Linux user):
github.com/Drewsif/PiShrink

Fantastic. Will do. Thanks.