Advanced Search

That´s it. Thank you very musch Crhis!!!

I also see that problem is master branch.

So I won´t resolve the problem updating anything, it´not a version issue.

Thank you.   
For a Rtelligent R6L028E I get to the installation stage where I can test for:

ethercat slaves -v      
and
ethercat pdos          
but
ethercat sdos        returns nothing. Is this to be expected or am I doing something wrong ?

Ok I see the probe screen is showing but the tab selected is main.
I also see that problem is master branch. I'll investigate.

ST-LINK (the hardware, at least) actually works fine for programming/debugging other vendors' ARM-M series ICs- used it a lot in the past for Nordic's nRF52 series. I was using OpenOCD, not the ST-LINK SW, though, and have never tried on a Cortex M7.

First thing is to triple-check connections- that you don't have wires plugged in off-by-1 in a connector. Also that everything is actually getting power (and what voltage it's using- 1.8V, 3.3V, etc.). I don't know where you got that pinout, but making sure it's correct wouldn't hurt.

It's been a while, but IIRC some ST-LINK models require you to have a target voltage reference connected- that may well be what the "???" pin is. It may help to probe that pin and figure out what it is and post exactly which ST-LINK you're using- official ST-LINK V2, some knockoff, the ST-LINK built into an STM32-Discovery board, etc. Again, it's been a while, but IIRC some of them have limitations I don't remember off the top of my head- might be they only worked at 3.3V and we were using 1.8V systems? My recollection is that the official ST-LINK V2 (not the isolated model, not the mini model) is the "good" one that works with everything.

You can also try reducing your SWD frequency to see if that helps, but I wouldn't be super optimistic.

Finally, I see in the MIMXRT1052CVL5B datasheet "Support for 5-pin (JTAG) and SWD debug interfaces selected by eFuse". I didn't probe further, but that implies that SWD could actually be disabled.

Good evening 

I've been using this iso successfully for a while now, i picked up a nice touch screen that works, but would work a lot better if i installed the displaylink drivers. Problem is that when installing this, i get an error that the linux headers are missing. 

Ive tried many of the usual commands to load the headers and nothing seems to be able to find the matching file. Have you got any insight or suggestions? 

If you would like specific error messages i can go through the motions and record these for you. 

Cheers!

i'm not into this stuff, but why would an ST programming utility connect to an NXP chip?

Hi Chris.

I tried creating a Probe routine in MDI mode, just in case I was doing it manually and it was my mistake. I'm getting the same problem in both MDI and MAN modes. I've attached screenshots from both modes.

Thanks a lot.

Same post here:
forum.linuxcnc.org/38-general-linuxcnc-q...n-4-axis-mode#347523

No double posting, please continue in the thread linked above.

the whole connection thing was already working on mesaflash and mesact, i could confirm with mesact, every test was a success. But Linuxcnc would fail, In the end I had to click on the network button top right and then it worked.

As for now i´m okay. Sorry for the rant, but I was used to it being easy setup with Pncconfigwizardo

You need to configure the network on the host for the Mesa card.

Also 192.168.1.121 is not suggested for LinuxCNC use as it's  in
a commonly used NAT range.

Suggested setup is to use the 10.10.10.10 address on the Mesa card
(via the IP address setup jumpers) and set  a static host address of
say 10.10.10.100/24.

At this point you should be able to ping the Mesa card:

ping 10.10.10.10

 

I mean i love the Mesa cards and Linuxcnc, but this card really made me reconsider using Mesa and Linuxcnc. The point where i broke was, after getting it to be recognized by mesaflash and mesact Linuxcnc would tell me network unreachable. This problem followed me through the whole process, either "network unreachable" or "no such device at 192.168.1.121"

EDIT: So far i got it running, but the whole process to get there is tiresome.

It would be normal to select MDI mode to use the probe after running a program.
You probably can't select tools, offsets or file in auto mode too.

let me know if I've misunderstood the problem.

Chris

Done!
Thanks.

Spindle mounted at the right side of the X axis, and all that mounted to the Z axis (see HiWin HGH25 left)

How the tool should be positioned during cutting, only the see-thru thin sheet over the brown (orange?) part must be cut, so about 0.5-1mm deep

C axis (3D printed round part with teeth for belt) is mounted above the Y axis and moves with it.

Full view of the important parts:

So far i have tried and tested over 10 configs, and over 40 scripts generated by Gemini, so this has become a late evening sport and an exercise in futility, although there were some moments when it seemed it is working, just to fail miserably.
None of those had TCP, just variations of axis/joints and different planes of works space.
Last two configs have TCP, and the subsequent failure to obey the joint/axis velocities and accelerations, the parallel port one a lot, the Mesa one less often so at least i can test a bit with TCP on and feed/speed lowered beyond useful.
And that brings us to:
Aciera, thank you for helping with this, i did not reply last night as i did not have much time to test, so gave it another go tonight (well yesterday, i see now it is 2:04AM here), so here are some of the results, probably in a non-coherent manner:
-in sim, it starts sine but after a short while it rolls/winds the C axis a lot as can be seen on the preview by the tool making a full rotation around the cut line, but in the same spot on the cut line, then continues nicely for most of the cut.
-on a machine, after fixing the limits and G53 0, it does the same thing, but here LinuxCNC errors out and stops the machine, even at very, very low feed rate and low max velocity, usually C axis at the beginning and Y axis a bit later. I am sure i read somewhere here about TCP causing this but could not find it, so i will try again today/tomorrow.
-the thing with C axis going from approx. 110 to -280 in about 10 lines of gcode does not seem OK, and i could not find what is causing that, it happens on several converted/filtered files, not just one, always after several lines of OK code.
-
Again, thank you, will report back whenever i can.