Advanced Search

Maybe some sed magic might fix it ?

meister wrote:

if we get rid of the errors in the w5500, i would of course always prefer this interface to the esp, as it is faster, reduces the parts and you don't have to program the esp as well.
Of course, the (r)mii interface would be even better, but the w5500 will do for now

That's the whole idea to have something as low-cost, easy to implement, small footprint/real-estate. That wizzy 5500 part win on all championships... I can count the required passives on one hand almost. Winner stuff. 

You said it better, anything to prevent having to impose an utterly complex implementation let alone adding a MCU + extra firmwares. Messyland guaranteed. Less is more!

Anything you need me to test with please do shoutout. I'm not far. 

to be clear, i have no idea about rtai/rt_preempt either, the hal component is also just a derivative of the remora project.
i'm not a good python programmer either, but when i set my mind to something i try until it somehow fits

Cant do this anymore bye all wrote:

Should RTAI be used with Ethernet ?
I thought RT_PREEMPT was the go, at least with the hostmot2 Ethernet driver.
 

Don't think for a split second that was a typo, I hardly make any difference between both rtai and rt_preempt. No kidd... so much to catch up, not even to the ankle level of guys like meister or yourself when it comes to lcnc devs. My bad btw... I should have been specific /RT/RTAI/PREEMPT/USPACE/WHO/WHAT... ... ...

Should RTAI be used with Ethernet ?
I thought RT_PREEMPT was the go, at least with the hostmot2 Ethernet driver.

Maybe immediate homing works for you, see section 6.14:
linuxcnc.org/docs/html/config/ini-homing.html#_immediate_homing

[edit]
Actually I think the above will still zero your position so not what you are looking for. Your solution is likely a custom homing procedure.

linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html
[edit]
All nonsense see below.

ARP & Ping are handled internally via the W5500, the only control is whether to respond to a ping or not.
After looking at info on the W5500 I read, whilst theoretically it can run an 80Mhz clock for real life 33Mhz is the max recommended.
As I said the packet issue seems to be random, you can have a period of 20000 packets be fine then you can 3 periods when the packets go south every 5000 packets and then be good for another 30k.
According to wireshark when the packets are delayed the data is good, no issues there.
Just wondering if rather than a combined r\w function in the driver whether it could be split. I have a feeling the Hostmot2 driver has seperate r\w functions. Maybe with a few functions added in between the read & write functions it may help.

Your consideration is much appreciated!! You're way too cool bud, thank you for what you've done for this community so far, no joke, it's EPIC <-- repost, take it.

Have a look and see if that's feasible. Problem on my side is not about keyboarding stuff but the Linuxcnc RTAI rather. I honestly wouldn't know where and how to test all that up, prolly would shave a month+ off my short life just to learn (min).

Side note; anyone telling you he/she's an expert in verilog and/or parallel-thinking is utterly lying to you. Bet there is only 5 persons on earth who master that brilliant e.e. mess of a codebase... (/rant_over lol)

if we get rid of the errors in the w5500, i would of course always prefer this interface to the esp, as it is faster, reduces the parts and you don't have to program the esp as well.
Of course, the (r)mii interface would be even better, but the w5500 will do for now

my knowledge of verilog is extremely limited and i would be happy to have someone with me who is more familiar with it.

I'm the last person who would complain about someone getting things to work in RIO that I'm too stupid for

i will test the new driver later at home, the integration into RIO is not so hard.

all what rio 'know' about the w5500 plugin is here:
riocore/plugins/w5500/

so, more or less, copy the new files into this folder and editing plugin.py:
changing list of verilog files:and add the new pin:
The only thing missing is this in the w5500.v:
sync: goes to 1 if a new package is received
pkg_timeout: goes to 1 if no package received for a while (parameter TIMEOUT)
tx_data: the data to send
rx_data: the received package

pkg_timeout is needed to trigger the error state of the CNC
sync is needed for multiplexed data
BUFFER_SIZE depends on the configuration and will be set while generating the rio.v

Hello everyone

I am having issues setting up my homing sequence for absolute encoders on my Ethercat servo dirves. I have read trough a few topics here on the forum but did not find the solution to my problem.

Background: I have Lichuan Ethercat servo drives with 23bit absolute encoders. From testing I have found out, that the encoder tracks 512 turns (-256 to +256) which combined with my 5 mm pitch ballscrews gives me a effective range of -1280 to +1280 mm. I need a distance of 0 to 1000 mm on my machine. On startup of LCNC, my encoder reports the correct absolute position of my axis. I have setup the homing sequence as follows:

To the issue: Let's say on startup I am at some random position e.g. 833 mm. LCNC now requires me to press the home button before I am able to switch to teleop mode or issue MDI commands. What happens now, is that the position of the axis is set to 0 and my two soft limits of 0 mm and 1000 mm are applied. This however is in my opinion not correct since the soft limits are now actually at 833 mm and 1833mm. This would lead to a crash if I were to move the axis. I need the homing sequence to keep the 833 mm absolute position value and apply the soft limits at the effective 0 mm and 1000 mm. Basically I need it to just set the "homed" flag and be done with it.

Hope I was able to describe issue somewhat clearly. Any ideas?

Thank you and greetings

Why is there stuff for parallel port?
If not, start over, make a new config, do not fill info at random.

Hi Arciera,

The feedrate is set from -100 to 0 to 100 % in the gui. It's like adaptive feed.

I have to add a overide like up to 120%, but that's peanut's to do.
If the feedrate is set at 100% the gcode feedrate is exact that value. For jogging it takes the gui settings page feedrate.
So at -100% the motion goe's in reverse, also doing reverse with endvelocity. Taking the vo as endvel.

Testing a surface, this file is huge so i did a memory preview cleanup first :


Ok after testing a few gcode files, i have seen a few things in the optimizing algo. I will document these and report.

meister wrote:

i prefer the WT32-ETH01, cheap and available

Understood, thanks for the advice/heads up. I have placed an order for the WT32-ETH01 and will receive this within 36~48hrs. I'll update. 

As important; For your review and consideration, Oliver.  I've quickly re-wrote a w5500 UDP protocol driver featuring a robust state machine and both a soft & hard reset (set on hard rst atm - preference). The SPI is a high-performance 50meg judging from the initial tests carried (see attached Gowin project/ZIP file). Additionally, please pardon my arrogance and persistence in trying to get this w5500 badboy to work; the reasoning behind is not fueled by my potential $1.99 investment losses (lol) I assure you, but more or less by the enthusiasm of that wizzy part being as simplistic as they come - let alone a ridiculously low-cost BOM and beyond ease for hardware implementation. All good reasons if RIO is to be adopted by makers like myself (iThink). 

You guessed; I wouldn't know where to begin neither would know how to implement this into RIOCore. Therefore I leave it to you to investigate that possibility (or feasibility rather).




 

That is nice that they used switches. Schaublin embeded Hall sensors into the bed of the 125-CNC. I hope they dont fail.