Advanced Search

Hello,
Could you please help me with my tool changer, my machine is cnc endmill  emco 55 pcmill. I am using Carousel Component with counts mode, since I have a stepper motor on the tool changer.I also have a sensor that connected to sens-0 (index)at this point I can move and home the car, I can also do the tool changes.the last thing that I need to do is move the carousel back home once the tool has been changed. How can I move the car back to home with a subroutine?My tool changer does not have an arm that I can control.

Thank you, 

Heh. I would have to say probably "yes", to both. LOL.

It's a DIY mill. In 1993, II got it as a kit, which included the stepper, a driver board (which did just raw coil driving -- not even step/dir!) along with plans for a chassis made of particle board, rails from high quality drawer slides, and all-thread rod as the transport. The s/w that came with it was written for DOS, polling loops and all.

There have obviously been a lot of upgrades over the years: EMC/LinuxCNC in 2004, acme rod for X and Y (Z still uses the all-thread) a lot of chassis strengthening, a real step/dir driver board maybe 10 years ago, and a Mesa card and Raspberry Pi this year. But it still has the same steppers, and the linkages and threaded shafts aren't all that well aligned. Frankly, I'm amazed it all kind of still works. But I have fun with it... when it's not driving me nuts!

Pictures here: projects.foxharp.net/cnc/

hi，thanks！
It doesn't work too. However, I find something in rtapi.h file.
I think it is not like the linux kernel modules.

#if !defined(__KERNEL__)
#define MODULE_INFO1(t, a, c) __attribute__((section(".modinfo"))) \
    t rtapi_info_##a = c; EXPORT_SYMBOL(rtapi_info_##a);
#define MODULE_INFO2x(t, a, b, c) MODULE_INFO2(t,a,b,c)
#define MODULE_INFO2(t, a, b, c) __attribute__((section(".modinfo"))) \
    t rtapi_info_##a##_##b = c; EXPORT_SYMBOL(rtapi_info_##a##_##b);
#define MODULE_PARM(v,t) MODULE_INFO2(const char*, type, v, t) MODULE_INFO2(void*, address, v, &v)
#define MODULE_PARM_DESC(v,t) MODULE_INFO2(const char*, description, v, t)
#define MODULE_LICENSE(s) MODULE_INFO1(const char*, license, s)
#define MODULE_AUTHOR(s) MODULE_INFO1(const char*, author, s)
#define MODULE_DESCRIPTION(s) MODULE_INFO1(const char*, description, s)
#define MODULE_SUPPORTED_DEVICE(s) MODULE_INFO1(const char*, supported_device, s)
#define MODULE_DEVICE_TABLE(x,y) MODULE_INFO2(struct rtapi_pci_device_id*, device_table, x, y)
#define MODULE_INFO(x,y) MODULE_INFO2x(char*, x, __LINE__, y)
#define EXPORT_SYMBOL(x) __attribute__((section(".rtapi_export"))) \
    char rtapi_exported_##x = #x;
#define EXPORT_SYMBOL_GPL(x) __attribute__((section(".rtapi_export"))) \
    char rtapi_exported_##x = #x;



 

pgf wrote:

Ha!!! My motors stall if I go much over 40 inches / minute!
 

That seems exceptionally slow.

Is there a problem with your machine - perhaps axis binding - or do you have really undersized motors?

I suggest trying to work with this file. I still need to clean it up a little, but this is a far better starting point than the ai file

github.com/cakeslob/RRW_LAB/blob/inc/Lin...theng/remora-xyz.hal
github.com/cakeslob/RRW_LAB/blob/inc/Lin.../remora-xyzRE_ts.ini


I mean....big red flags from ai file

Perhaps it is related to the EOE mode of the drive. Generally, it is recommended to adopt the drive in COE mode...

Mainly for my own records and thinking aloud.......
Switched from the i5 & Realtek NIC to a RPi5. Seems somewhat more solid, can get Mesaflash to write reliably with a 8us usleep instruction around the "sync" instruction. Still thinking the issue is my side, have ordered some "sample" interface chips from Microchip, I'll assemble another board, this time using a reflow oven for the SMD parts. If that doesn't fix it I have a board designed for the OMDAZZ dev board I've used before, SPI just needs upgrading to 16Mb part as it only comes with a 4Mb part.

I think about 6 months ago a user tried to use ChatGPT to write a component for Linuxcnc...what a mess that was and the user was quite upset, not so much with the code supplied but with the fact that the replies suggesting the code made no sense.

Thanks for your input. Keyboard input is USB, so meh, not a lot that can be done about that.

Use the official fan & heatsink, it works well and you'll have no issues. I've left mine on for days at a time during the summer in Australia and nothing has gone wrong.

I prefer a wired pendant, connected via a Mesa 7i73. It's solid and you don't need to worry about disconnections. Just axis & step selectors with a hand wheel. Tho Rod does us a fancy wireless one.

Ha!!! My motors stall if I go much over 40 inches / minute!

Rod, all my 3D printers run Klipper on laptops or NUC's, nothing runs on RPI's on my shops, although i have 2 somewhere, the 3B version.
Use KIAUH from github, it will install and setup everything on a PC, including camera, telegram bot, etc

First of all, thank you very much for your work with the images. 

According to everything I found on the net, a pi 5 8GB with SanDisk extreme pro 64gb, official power supply and a Mesa 7i96s should work without any problems? Is that correct?  

Are there any restrictions regarding
- user interface (probe basic, gmoccapy)
- the wireless 6 axis handwheel  

One last question about the cooling / housing.Is a passive cooled case like the Flirc Raspberry Pi 5 case sufficient or should active cooling be provided? My thoughts on this are mainly dust protection.


Perhaps useful for others
Unfortunately, the standard office monitors all have large ventilation slots on the back. I have been looking for alternatives for a time and would now like to use a mobile external monitor (sold as a supplement to the laptop). These seem to be much better protected against dust.

Thanks 
Erwin 

So this code does the same thing?
(pwmgen.00 is the spindle pwmgen)

Second hand laptops are much cheaper and much more powerful, and can easily run Klipper.

I didn't know that!