Advanced Search

Hi. How to change code to work without index and position signal. Like Boxford type turret driven on stepper motor. New in LinuxCNC.

Edi_48 wrote:

Starte ich eine Maschine bekomme ich eine Meldung das kein Netzwerk habe , Ping keine antword.
Wenn ich Netzwerk neu starte habe ich wieder einen Ping.

 

Seems like wiring/EMI issue.
How is the Mesa board powered ?

No it’s not a SPI to Ethernet converter.
It’s a chip that has an SPI interface and implements a, for lack of a better description, a network stack.
A micro controller connected to it still has to setup network related things, monitor it for received data and other such tasks.
So no it does nothing to increase the distance between SPI devices.
I suggest you go to the wiznet site and learn what that device actually does. From memory they use the 5500 device.

Hello tommylight,

That Google excerpt could be way off. I don't know. The only way to know what the current state of (LinuxCNC/Pi 5) is to poll it users and those attempting to use it. As you say they may have a working system and be doing something else.

Your comment about "Set it once and never again" is true for a lot of software until you change something (like a controller or the software itself).

I know newbies don't read things. For me "usability" includes reducing the need to read stuff as much as possible.

A issue list/process has several attributes besides being a pain in the neck. One is to track issues that surface and ensure that the issue is fixed and available for download. Another is for the developers to assess how to improve the user's encounter with the hardware and software itself.

I offered to help. If there is no issue list (for PI 5 for now) maybe I could help to create one. It would help centralize some aspects of the development work. Also, people age out. It may allow the current crop of wizards help the next generation of users.

Thanks,
Tom

Agree with Tommy.
Users skipping steps.
Users not typing in commands properly.
Users not relaying requested information.
Users blaming Linuxcnc when it’s a mechanical issue.
Users blaming Linuxcnc when it’s an electrical issue.
Users not bothering to look at the docs.
Cases of users editing config files with a word processor program.
Users not understanding the prepared Linuxcnc images are not meant to be a general purpose OS.
Users believing the fear mongers who will say you need to be a programmer.
Users thinking they are the first and only ones to have a particular issue.
Users who don’t know how to form a proper question.
The effing “Maker Community” that tells poor saps that a CNC machine is easy to use by anyone.
People that wear gloves near rotating machinery.
People that insist on soldering crimped connectors.
Ah fuck it just people in general.

Meine Dateien
 

BSOD wrote:

Okay. I'm officially lost. I can't get the stepper motors to work normally. Everything else works or would work with a few configuration changes if the movement was resolved. With the ec300-rt1052.txt configuration, the steppers have the grinding sound you can hear in the linked video.

BSOD, I've had a similar issue before, and in my case, it was caused by the wiring of the stepper drivers. I would suggest trying the following:

1. Connect all the V+ pins of the stepper drivers to the Common pin of the EC500.
2. Then, connect each signal (Step & Dir) from the EC500 to the negative pins of the drivers.

If your current setup is already configured like that, try reversing the connections, i.e., connect the V+ pins to the negative pin of the EC500, and the signal pins (Step & Dir) to the Common pin.

This adjustment worked for me in the past, so hopefully, it will resolve the issue for you. Let me know if this helps!
 

As far as I understand it, ideally there should be no offset.
The offset is there because the algorithm only matches velocity
and does not do the calculations needed to match velocity
_and_ correct position.

zelo wrote:

I have my config here for ec500 with nvmpg: github.com/zelo/linuxcnc-remora-ec500-rt1052-cfg 
Thank you, Zelo, for your response.

Unsurprisingly, your EC500 config file didn't work with my NVEM V5 board. So what I tried next was to git clone the repo named Remora-NVEM instead of the one I used previously named Remora-RT1052-cpp. However, when I uploaded the nvem-full-config.txt to the board, it messed things up, and now nothing works. It doesn't even accept any other config uploads anymore, and I'm stuck. I think I would have to reflash it and start all over again.

Anyway, back to my original problem: The outputs of the NVEM V5 board are all unresponsive, no matter what config I use. If anyone has a working setup for the output pins with the NVEM V5 board, please share it. Thank you so much.

By the way, just for a sanity check — when the output pins are high, should they be outputting 12V? What I'm doing is measuring all the OUTPUT(+) pins with COM(-), but I get a 0V reading. I assumed it’s not working, so any guidance would be much appreciated!

I’ve attached a picture that shows the difference between the responsive and unresponsive pins for reference.

 

thanks for the info tommylight. Right now I am in the information gathering stage that way if the US government wants to
get belligerent with tariffs I have a means of dealing with it.

Well that google sucks, hard.
There are no "instability issues" ever, you set it properly once and it keeps on working for years and years without issues, ever!
"steep learning curve"??? Yes of course, for someone with no prior experience, but so is tying shoes when we are young.
"compared to commercial CNC controls", i have no clue what they are comparing it to as from extensive experience i concluded the opposite, although some do come close to actually pointing issues in the right direction, some will absolutely make you take a hammer and destroy the thing.
"many users report frustration with the complexity of setting up a reliable system" Oh YES! This is absolutely true due to reasons:
1. They do not follow instructions! Read some random topics here, like setting up networking for Mesa cards, or servo tuning, most people will read and configure things and move on, but there are some that skip steps and come back complaining nothing works.
2. those who managed to set things up are not here complaining, they are making chips and using their machines, and most do not bother registering here, so google can not include those, and that is the majority of LinuxCNC users.
-
In short, LinuxCNC is extremely reliable, very easy to set up for normal machines thanks to several wizards that are included with it, but there is NOTHING easy for retrofitting a 15 Ton industrial machine without prior experience in electronics, and yet, there are plenty of members here who did just that with no experience at all, they just followed instructions from very experienced and capable members of this forum.

Thank You for the response!
I had the machine running with a parallel BOB. I have microsteps, current, acceleration configured already, did not change those. Steppers had a "healthy whining" sound. Only the EC300 is new.

The "faster" DMAstepgen doesn’t generate any movement for me. As far as I know, you can only set timings in DMA configuration.
My timings are exactly as Yours.


 

I'm getting the feeling that Rob Ellenberg's spindle synch updates/re-writes were never incorporated in to LCNC mainstream.

www.mail-archive.com/emc-developers@list...ge.net/msg16956.html

 

radom wrote:

will that get somewhere marked as a bug/something to improve in the future or will be forgotten in a week's time?

I'm interested, and despite my utter lack of programming knowledge I've been poking around on github looking for anything obvious.

My inexpert opinion is that a thread start point that varies with spindle speed is a bug - not expected behavior - at least according to the user manual:

G76:G33:
So according to the the user manual author(s)' expectation, the start point should be a calculated position with compensation for spindle speed and axis accel/maxvel values.

I did find that the section of trajectory planner file (tp.c) Chris posted earlier was edited a few times in 2009.  I've no idea whether the change(s) have any affect on the situation at hand.

I see that there is an open Issue on GH - 8 years old? - that may have something to do with this, as well as some more recent (possible) resolutions:

github.com/LinuxCNC/linuxcnc/issues/167

github.com/LinuxCNC/linuxcnc/pull/479

github.com/LinuxCNC/linuxcnc/pull/581/commits

I can't tell if #581 fixed, broke, or had nothing to do with spindle synch/threading start point calcs.

I think more testing is in order.

First, I'd like to see if G33 behaves the same as G76 does.

Second, I'd like to see if the thread start point varies by a predictable amount depending on

• spindle speed
• encoder resolution
• axis max accel
• thread pitch

If the offset is predictable, that suggests to me that position math is being done... but some programming is wrong.  If the offset is not predictable,  then my guess is that position is not being calculated per the G33 user manual section.

I'm sure some of the folks reading this can review files like tp.c and understand the behavior, but I can't.  What I can do is poke around and see if something obvious crops us.

I've got a fairly high-res encoder on my project lathe, as well as fairly 'dynamic' Z-axis accel.  I'll try to run some basic G76 and G33 tests this weekend and report back whatever I find.  Maybe with a high enough encoder res and accel values, this is a non-issue... and below some set of values the underlying problem makes a (negatively) meaningful difference in threading results.
 

It is possible to solve the problem related to distance and speed by using a spi to lan converter similar to the module below
And it had a real time component
www.amazon.com/HiLetgo-Ethernet-Network-...Z820io/dp/B08KXM8TKJ