Advanced Search

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.

I appreciate your response, but I am not sure we are talking about the same thing.

Can you elaborate on how a potentiometer would work as a switch?

So appreciated! I will go take a crack at that right now.
I disconnect ALL the power! always.

dc

Do you already have the switches?
If not, use potentiometers, cheaper, easier to wire, and linear regulation/range/etc

sawdust wrote:

I tried reversing the motor phase connections on one driver/motor and the motors still both spun the same direction.

One winding ONLY, not both, and not phases.
Single phase, one winding, two wires, that is the only thing you need to change for it to change direction.
Edit:
NEVER while the drive is powered!!!

Is it a subtle difference? I don't see a difference in zooming with your changes.
It certainly didn't hurt anything ti have it in.