Advanced Search

hello Chris, instead of making another post, I would like to add a little something here regarding the variation of the circle diameter

mouse scroll only - scroll circle diameter 

may now work a little slower than in previous versions

It would perhaps be practical if the currently set value according to the

middle mouse single click - cycle through rotation increments 

would also be used to adjust the diameter?

This seems like a good suggestion.

I suppose by "binary" you mean digital (is that the Australian way of saying digital?) as opposed to analog. Are you saying I don't need analog pins at all for this? I still want to know how to do this kind of thing with analog pins, even if it's just for a learning experience. I am literally starting from scratch here, and I already have the switches and 1k resistors.

Also, seems like mux4 has a limit to the number of selections on a switch. What if I have a switch with 7 selections I want to make? Or 9? I don't know any more know now than I did before about the physical wiring.

And for a bit more proof in the pudding some pictures of the results of a sharpie taped to the plasma head. 

 

Many thanks Zayoo !

i have add the code to the dev branch for testing.

if you want to use it, you can addto your json config

like this:

Perhaps it's my imagination but it seems like Google in the past was better at searching out general information, lately it seems to favour merchandise over information.

I registered just to say thank you for the software JMParts. 

Pleas use Balena Etcher instead of the Pi Imager if you can't burn an image. It is much more reliable

I would recommend you use a binary rotary switch and the mux4 component as outlined in the documents for scale and axis selection.
linuxcnc.org/docs/stable/html/examples/mpg.html
Using binary inputs makes frugal use of inputs (4 states only needs 2 inputs)

martyop post=316224 userid=3221
Thanks for your reply.

uname -a reports
doodle jump
Linux garage 6.1.0-28-rt-1md64 #1 SNP PREEMPT_RT Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux.

The garage computer has an intel atom processor.

It is possible that the issue is related to the real-time kernel configuration on Debian 12. Please check if the kernel is compatible with LinuxCNC and make sure the system configuration is optimized for real-time.

Hi everyone,
Lately I have been annoyed by the loud grinding noise of the Z axis and the slow speed at which the farm robot moves - it is too loud for anyone walking into the greenhouse to hear, and it is very slow.
I know that graphite lubricant can be used on the drive shaft, but that doesn't help much. I recently listened to the motor at high speed, and surprisingly, it was much quieter. It is still a bit slow, though.
I have six NEMA 17 stepper motors with sun gear reducers, encoders, and hardware available to modify them. They are much faster and very quiet.
I have also looked into using PTFE plastic rods instead of the aluminum Z axis drive shaft, as this plastic is oil treated and has lubricating properties.
Does anyone have any ideas? I think this should not be difficult to execute.

michaeln wrote:

Does the spiethconfig work for anybody?
I tested a lot, but i don't find the problem.
I insert printf commands in the code and get strange outputs. I change from picocom to putty, the same.

The command in short and long version:
spiethconfig -s 19 -i 23 -c 18 -e 0 -t 4
spiethconfig --miso 19 --mosi 23 --sck 18 --csenable 0 --interrupt 4
The output:
Invalid or missing Chip Select pin (0>128)
Command returned non-zero error code: 0x1 (ERROR)

I insert some printf-commands ( bold my changes):
            printf("argc: %d\r\n", argc);     

            if (result.count("s")) { miso_pin = result["s"].as<int>;(); }
            printf("MISO pin: %d \r\n", miso_pin);
            if (miso_pin < 0 || miso_pin > 128 ) { printf_P(PSTR("Invalid or missing MISO pin (0>128)\n")); return EXIT_FAILURE;}
            
            if (result.count("i")) { mosi_pin = result["i"].as<int>;(); }
            printf("MOSI pin: %d \r\n", mosi_pin);
            if (mosi_pin < 0 || mosi_pin > 128 ) { printf_P(PSTR("Invalid or missing MOSI pin (0>128)\n")); return EXIT_FAILURE;}

            if (result.count("c")) { sck_pin = result["c"].as<int>;(); }
            printf("SCK pin: %d \r\n", sck_pin);
            if (sck_pin < 0 || sck_pin > 128 ) { printf_P(PSTR("Invalid or missing SCK pin (0>128)\n")); return EXIT_FAILURE;}

            if (result.count("e")) { cs_pin = result["e"].as<int>;(); }
            printf("CS pin: %d \r\n", cs_pin);
            if (cs_pin < 0 || cs_pin > 128 ) { printf_P(PSTR("Invalid or missing Chip Select pin (0>128)\n")); return EXIT_FAILURE;}

            if (result.count("t")) { int_pin = result["t"].as<int>;(); }
            printf("INT pin: %d \r\n", int_pin);
            if (int_pin < 0 || int_pin > 128 ) { printf_P(PSTR("Invalid or missing Interrupt pin (0>128)\n")); return EXIT_FAILURE;}

and get the result:
argc: 7
MISO pin: 19
MOSI pin: 23
SCK pin: 18
CS pin: 255
Invalid or missing Chip Select pin (0>128)
Command returned non-zero error code: 0x1 (ERROR)

After that i change the sequence of the variables, the problems stay at the forth position. i saw that the out from argc stay at maximum 7 (in my opinion it should be 11).

Does it work for anybody?
If yes, what does is made wrong?

Thanks and best regards
michaeln

Hello,
now i found the problem of the SPIConfig.
Here is the code with my changes, forked from sybexx with his changes:
github.com/michaelnu/ESP32_LinuxCNC_MotionController_RealTime
Best regards
Michael

 

Thanks to the wonderful efforts of everyone recently, I have been able to get my 7c81 working excellently with my Raspberry Pi 5 on the 2.10.0~pre0 (self built) version using the `hm2_spix` driver.

I have a lot of configuration and testing to do, but thus far it seems to be working flawlessly. 

I did have a few things to get it working the way I wanted, one was getting remote access and spi working for flashing:


I also had to replace the hm2 module load with the spix version in the `foo.hal` file.




Ignore the mess of wires, I need to get some mounting stuff figured out, plus all of the plasma cutting controls and so on figured out next too.

Hallo,

schön, dass du die Frustrationsschwelle "verschoben hast"
Ich vestehe nicht ganz, was du verändern möchtest. X-geht ja "eigenlich" immer von "links" nach "rechts" und y immer "vorne-hinten".
Soll die Beschriftung am Bildschirm getauscht werden?
Die Zuordnung der Antriebe könnte man ja einfach durch umstöpseln der Motoren erledigen, oder in der *.hal die zugehörigen Mesa-Ausgänge vertauschen.

Gruß Timo

I wish I had found Marks saga before I finished my Maho MHC700 restoration. Not an obvious place to start looking for a Heidenhain controlled machine. My machine has a TNC 155 retrofitted and you probably have read about it's rebuild on Marks thread. Your TNC 355 is very similar. It just has a bit more memory and speed. So it has a few more machine parameters tacked in the end of the TNC 155 list and probably runs a bit faster.
The one really lucky break I got was the Heidenhain worked perfectly first time. All I had to do was load in the machine parameters and swap it to English. Fortunately I had them on paper tape and hand written in the manual.
But that situation didn't last. Recently it started to get some fold back at the top of the BE411 monitor. Not the end of the world, but I couldn't read the line number in graphics mode, making testing programs a bit difficult. The problem is almost always the electrolytic capacitors so I read up on how to not kill myself changing them. Disconcerting things like putting one hand in your pocket whilst shorting the 22000 volts on the plug on the display tube with the other, so you don't draw the voltage across your heart if you mess up.
There are about 25 of them if you do all of them like I did, and there a few difficulties and traps to know if you want to try it on yours, but it came up perfect. Crisp and clean without doing any adjustments. About $60 Australian from Farnell in the UK. 3 days deliver to Australia. And the capacitors are smaller, have up to 5 times the life even at a much higher temperature rating.
In hindsight it might have been easier to do that on yours to debug the circuits then go to LinuxCNC.
The problem with the Heidenhain is you have a TI processor of about the same era an IBM PC AT with an Intel 80286. 16 bit and about 8MHz. And you are limited to simple pocketing and pecking.
With your setup you have the advantage of updating you PC forever and a wealth of open source programs. To get to the next step I'm going to have to get familiar with Fusion 360 and drip feed. Heidenhain has a nice serial coms program that works for all the machine they ever made Fusion 360 has a post processor file that works for my machine. I've been doing my modelling in SolidWorks for the last 30 years so it's not that big a step.

BTW. On mine, once the 220 volt power is latched on by 19K1, it goes through the 3Q1 circuit breaker, then to the  3F1 pressure switch on the hydraulic pump, then back the the hydraulic pump contactor coil 3K1 and runs the pump. The pump run is very brief as there in no hydraulic accumulator on my machine. It runs a lot longer to release both chucks or the CNC rotary table. The Vogel lubricator also runs straight from 3Q1 also and is actually powered by the 220 volts. So it does a lube cycle every startup, then goes to timer based lubrication cycles. So a dumb system not controlled by the CNC controller.

Cheers,
David

Instant fix. Tommy, thank you. I have been slamming my head against that for days.