unknown wrote:

So.....you are wanting testers for a closed source hardware project
What's in it for the testers ?

 

I don't want you to be my free testers. image missing /media/kunena/emoticons/smile.png
To do this project I came up with, I first experimented on a breadboard and then created the PCBs with the features I wanted. Unfortunately, I made some youthful mistakes in hardware development... trivial but significant...
I redid the PCB designs but haven't ordered them from the service yet. For now, I've already spent enough money on a "gamble." image missing /media/kunena/emoticons/ermm.png
If you want, there are some kits that need fixing, so it would arrive with various jumpers soldered on the fly.
In any case, the eval version is fully functional like the final one, but it doesn't have all the peripherals enabled. image missing /media/kunena/emoticons/cool.png

Hi all,I’m currently having trouble setting up a tool presetter in LinuxCNC. My setup consists of a Raspberry Pi 5 running LinuxCNC, three Leadshine servo motors, and a Beckhoff unit handling the toolsetter input.

The main issue is that when I press “Set Tool Offset PSO,” LinuxCNC does not apply the current machine coordinates. Also, when attempting to perform a tool height setting, nothing happens.
I’m also experiencing problems with manual tool changes. When using the Unload Tool or Load Tool commands, nothing occurs. The only way I can trigger a tool change is by using an M6 T"x" command, which brings up a popup asking for confirmation that the tool has been changed.I have not yet connected the solenoid valve that will actuate the drawbar. 

I’ve attached my HAL and INI files. Any suggestions or ideas would be appreciated. 

meister wrote:

2. Closed Firmware & 'Over-engineering' I respect the Open Source philosophy, but io_decoder is a professional project that includes dedicated hardware. The 'over-engineering' you see in the HAL driver is actually optimization. While a user-space component can work, a dedicated C component ensures deterministic polling and much lower jitter. If you want a 'professional feel' on the handwheel, those milliseconds matter.




ahh, ok, This is what professional code looks like when compiling.

Code:

halcompile --compile io_decoder.c Compiling realtime io_decoder.c MEGACUT [i][i][i][i][i][i]Linking io_decoder.so[/i][/i][/i][/i][/i][/i]

Code:

[i][i][i][i][i][i]“Bare-Metal” Firmware (No Bootloader) We have removed the Arduino bootloader for two critical reasons: Safety: No random pin state changes during startup (typical of bootloaders). Speed: The board is operational within a few milliseconds. what about updates ?[/i][/i][/i][/i][/i][/i]

 

Thank you for alerting me to all those warnings... apparently my system is set up so that I don't see them... I'll try to fix everything in the next few days... they're all warnings for things I left lying around due to closed roads and changes of direction in the program.

As for the choice to remove the bootloader, it's because I didn't want every communication, which occurs every 20ms, to waste time trying to figure out whether it was a new program or a regular message about the work it's doing.
If you want to modify the firmware, you need to use a programmer like tinyusb.
 

COFHAL wrote:

I use Arduino Connector, I really like your project, it's very professional. I don't know if you plan to create matrix-type keyboards to simulate keys or to be used as HAL pins like in Arduino Connector, which gives great flexibility.

 

There's no direct support for a matrix keyboard; I had considered it during the project development phase, but I was too far along and would have had to completely overhaul everything... perhaps in a future version...
However, all the inputs have the keyboard functionality that allows them to send keyboard characters with the physical input pins.
the only difference is that you have to wire all the buttons one wire for each button + the common which must come from the io_decoder board
It's all explained in the docs on GitHub.

Hi,

how can I help you exactly?

USB Stability & Real-Time Thread I’m well aware that USB isn't for the Servo Thread. 

What thread will it run in ? And you suggesting another thread to add to a config ? What period would this be run at ?
How would that affect a config that has a base thread (for software step gen) and a servo thread for other functions ?

To clarify the threading model:
does not run the USB communication inside the Servo Thread.The component spawns its own dedicated asynchronous thread to handle the USB protocol. The interaction with LinuxCNC’s HAL happens via non-blocking data exchange.

• Zero Blocking: The Servo Thread never waits for a USB response. It only reads/writes to a local buffer managed by the driver.
• Base Thread Integrity: Because the USB communication is decoupled, there is no risk of inducing jitter in the software step-generation (Base Thread).
• Responsiveness: This architecture allows us to maintain a high polling rate for the handwheel and I/O without affecting the machine's motion control stability.

This is exactly why it's more stable than a generic HID driver or a simple user-space script.

ciao
Roberto

Have you download to drive the parameter file i attached?Check the manual for the Asda-A2 drive has more detailed infos.

Hello,

I was planning to bore out a disc yesterday and thought I'd handwrite the code. The circular path would be 105 mm in diameter with the center at G54 X0, Y0, and starting at position X-52.5 Y0. Because of my lack of experience, I wrote is as a small program so I could get a preview. But the preview is not what I expected for the: The arc is started from position X-52.5, Y0.

As you can see in the screenshot, the preview shows a strange linear movement and a counter clockwise helix. But when I run the code, the machine makes a 105 mm circle in the XY plane, just as I wanted. The path from this run is visible as well (the red line). I'm guessing I'm doing something wrong, but what?
 

Hi,
Empty

Code:

My apologize ... sorry I can not show same speed test because I am currently weeks out of office but we can just multiply or devide values ... because it is linear dependecy during constant speed movemet ...  I can just customize current images to show exact difference ...  compensation off ferror = 0.125mm at 15m/min ...  compensation on ferror = 0.00009028mm at 1m/min and multiply it by 15 we get 0,0013542mm which is significantly less then 0.125 .. What I remember from testing by my short eyes it whas something near 0.001mm during that 15m/min testing was done with bentch top setup without any load presented... just AX5106 with AM8xxx motor  but I can go home for testing this weekend to create exact speed difference testing if it is neccessary No apologies needed [img]/media/kunena/emoticons/wink.png[/img]

 

I can understand You and YangYang, its added job, but I openly disagree ... its the best time to improve lcnc and solve it at native level for ever, no other proforma hobby solution as now my is...

it should be solution for everyone who not understand it soo well as you guys... my solution of compensation will be even more inaccurate when scurve will be done and implemented ... 

I can not say you what to do, your job, your rules, your output ... thanks for your upgrade to curving
 

One way to help diagnose this (assuming it's a hal issue)  is to run
LinuxCNC, and then turn on the spindle at 1/2 speed.

Then, in a terminal window, type:

halcmd show all | grep spin > spindle.txt

and post the created spindle.txt file here.

But I have homed the axis and the little diamond, or whatever it is, is showing next to it. But Touch Off gives this error message.  I have been using this INI file for months without problems. This is a Sherline mill so there are no limit switches. The only axis that homes is A, which is not connected. It homes and sets to 0.000.

The 7I76R14.BIN image will not work as there are two program images
in the DSPIC code (the setup and working images) This is done to allow
live updates.

This is the complete 7I76 image:

 

 

Hallo,
und danke für die Antwort Luca, ich lasse mir etwas Zeit, sorry. Der Rechner läuft noch nicht wieder, ich strukturiere gerade meine EDV neu, Winterarbeit. Sobald das erledigt ist geht es hier weiter, ich melde mich, das ist bestimmt noch nicht die letzte Frageimage missing /media/kunena/emoticons/smile.png.

Gruß
Mario