Advanced Search

I've calmed down now and want to try the ecad.so module.
I searched around a bit after your code, but don't know how to pull code for ecad, or how to build it.
Can you provide some instruction?
Also, do I need your version of lcec and lcec_conf? Seems old, it didn't recognize float-ieee haltype.
And you have Ethercat master code, do I need that or can I use the distributed apt packaged one?

I wonder did you fully reverse engineer the commands for velocity mode?
Are you sending exactly the same values as the original controllers do for the selected RPM?
When I had a look at it last time I found out that the values don't directly translate to the requested RPM value, at least there's no linear mapping, it is a little bit off from time to time.

Read through this thread, there is an example in this very thread.

you should have homing to index enabled and working, then you have to align gantry to be perfect square, when homed. And if you use velocity mode with PID, then the linuxcnc uses real feedback from motor encoders. So if you disable servos, and move axis by hand, the position is reflected in linuxcnc and you dont have to re-home. Same with gantry. it will square back.

The best option would be to add 'XYZBC' mode to 'probe_basic.ui'. If that is not something you can do then you'll have to convert to 'XYZAC' as you mentioned or hope that @Lcvette has a look at this issue.

I have installed the PI5 image (25-01-27) and have gotten everything working EXCEPT the hal_gpio input pins. Outputs...done, inputs... no luck. I can read the input pins with GPIO from python... but not within linuxcnc.

Any ideas?

The OHMIC TEST button does not move the Z axis.  The intent is to see if there is a short between the torch tip and the ohmic lead (a ball of oxide can do this, or water from a water table).

User Manual Explanation of OHMIC TEST

If you do have a short, or you create a short to test it, you also need to hold the button to get the OHMIC light to light up in the GUI as there is sometimes a delay.  The click you are doing is far too fast.  

Ok I tried fixing it again

Hey that is awesome how you customized the Axis interface like that. Is there a way I can get a copy of that to use on my machine? I really need a search feature in Axis for the GCode so I'm able to goto a specific line and rerun the cut. Like so Im able to search for M6 T1 or M6 T3, T4, T5, etc.... and then re-run the code from that line after changing the tool diameter and making fine tuning of the parts using cutter compensation and or fine tuning the coordinate shifts. Anyways cool! I need this too

It was dist-upgrade being the issue, upgrade is fine as the kernel is pinned anyways.

As usual your comments add nothing to the discussion.

Hello scotta,

thank you for your quick reply. Yes, that is exactly what I thought myself.

The EC500 is powered by an external power supply. From the 6 pin header, GND, SCK and SDO have been connected to one of the probes.

I don´t have any kind of schematic on hands for the EC500. So I am not shure, why the header pin is labeled SDO. I would expect SDIO for a sufficient SWD connector. Is your header labeled with a SDO too?

My EC500 is labeled with IMXR_EC500 2023-05-18

Up to now, there has not been a single successful flash. From within MCUExpresso, I am at least able to build your application.

If this is not going to be successful: do you think, your actual project with W5500 and raspberry pi pico is as powerful as the 1052 solution and could be a viable alternative?

Thank you very much. I will try to give more details tomorrow.

Cheers Julius

 

Hi Scotta, do you happen to know what the error I'm having means? It seems like it's not communicating with the cloud in any way.

Hi Julius,

Very strange that one of those combinations don't work, especially MCUExpressoIDE.

For flashing
1. board is externally powered from 24v, so no VCC connection
2. GND, SCK and SWDIO is all the connections needed to the CMSIS-DAP probe

When I've experienced connection issues, powering on the board as the probe is trying to connect to the MCU has helped.

Your answer is a technical explanation of why this is the case. However, I look at it from a user perspective. I take it that there is unnecessary information in manual and MDI mode. I understand that removing this is extra work, but it is not unsolvable.

zz912 wrote:

Is there any reason why "G-code properties" is also displayed in manual and mdi mode?

It is there in manual mode as well, because it is part of a box that is displayed in all modes, so this is also displayed in all modes.