Advanced Search

The existing VFD is an Invertek and it can not work with Ethercat - the reason I think about the exchange.
Why that specific one? Mmhh - I had Yaskawa components in another mill and was very satisfied with the quality and the GA500 with the interface card is relatively cheap to get here in Germany.

As Servos I use 4 x A6 OMC/Stepperonline

Have you implemented the zswap fix or tried looking at the memory allocated to the GPU ?

To be quite blunt this is a low priority issue, as the primary function of the image is to run a CNC machine. Which by all accounts it has done quite well, the only show stopper was the zswap issue for one user, but this was resolved.
I may sound like an ass and appear to be unhelpful, but as I said before it's a low priority issue and so far has not, no reports, has affected the operation of a Linuxcnc session.

Sorry, took a while to check this out as I did not have a working
test system with a EPP parallel port and Mesaflash/LinuxCNC.

Unfortunately, I am unable to duplicate the issue.

What I did was take a 7I90HD and corrupt the S EEPROM so the boot block was broken
then booted from the P EEPROM , reselected the S EEPROM and attempted to update
The S EEPROM via mesaflash:

 

So it still may be a host EPP issue of some kind.

Test system: LinuxCNC 2.9.4 mesaflash 3.4.9
Hardware: HP Elite 8200 SFF with on board parallel port
 

7i96S + 7i83 ?
Wen sie mehr als ein encoder brauhen, noch 7i85 oder 7i85S

A very common method was to start on Y configuration and then switch to Delta. The motor starter switched between Y and Delta (contactors).
Ask google or chatgpt for the reason.

Depends on what you are aiming at, but a standard chinese VFD controlled by Modbus/USB is a common way to get speed control of the spindle.
The rpms can be somewhere 50%-150% of nominal rpm. Low torque at low speeds, possibly balancing issues at high speed, but at least some variation up and down is possible.
USB/Modbus is somewhat sensitive to electric noise so it is usual to have USB serial/RS485 with optocouplers and line filter for the mains.

Good point about checking chrome://gpu, it shows a number of problems with graphics features, such as hardware decode being software only.

Graphics Feature Status
Canvas: Hardware accelerated
Direct Rendering Display Compositor: Disabled
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
OpenGL: Enabled
Rasterization: Hardware accelerated on all pages
Raw Draw: Disabled
Skia Graphite: Disabled
TreesInViz: Disabled
Video Decode: Software only. Hardware acceleration disabled
Video Encode: Software only. Hardware acceleration disabled
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
WebGPU: Disabled
WebNN: Disabled

 

Problems Detected
WebGPU has been disabled via blocklist or the command line.
Disabled Features: webgpu
Accelerated video encode has been disabled, either via blocklist, about:flags or the command line.
Disabled Features: video_encode
Accelerated video decode has been disabled, either via blocklist, about:flags or the command line.
Disabled Features: video_decode
Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Expose WebGL's disjoint_timer_query extensions on platforms with site isolation: 808744, 870491
Applied Workarounds: enable_webgl_timer_query_extensions
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
Avoid waiting on a egl fence before swapping buffers and rely on implicit sync on Broadcom GPUs: 938286
Applied Workarounds: rely_on_implicit_sync_for_swap_buffers
Disable GL_MESA_framebuffer_flip_y for desktop GL: 964010
Applied Workarounds: disable(GL_MESA_framebuffer_flip_y)

Full report attached below.

I don't think the issue is hardware or resolution, since it is just this image that has these problems.

Small update. When there is no g96 /G95 command in the program, the program calculates the approximate time correctly. Maybe feed per rev is not calculated correctly. Thanks for the great work! I understand that this problem is not in the field of gmoccapy

Thanks for the report, this has been fixed.

JT

Hello EmilDLo,
mine is right now working with your config. I can start it up to explicit RPM, change RPM and even stop without problem. I didnt change anything on your XML, Ini or hal, so your problem completly is in your VFD set up.

Thanks for that, nice touch having the interval/on times adjustable from the status page, very handy.

The WLED should be great for general status conditions and minor warnings at a glance, looking forward to adding some bling to my machines.

Cheers.
Russell.

I managed to resolve it. Turns out those boards are maybe not for the same type of encoder? The sin and cos were inverted and so were their + and -. The connector was also mirrored the wrong way. I managed to cross the DB15 connector pins in a way to get it to work, though, and I can happily report it's basically plug and play after that. All that's left is to play around with the resolution with the jumpers a bit...

a little tip on what you can do with the wled's to display the status:

 

in dev branch and untested (only via testbench):

github.com/multigcs/riocore/blob/dev/rio...s/interval/README.md

little config example 10 seconds on / interval 20 minutes default
looks like this:
 

and the onTime can be adjust between 5 and 20 seconds / interval between 600 and 1800 seconds (10 - 30 minutes)

 

i will add a new plugin named 'interval' or so.
then you can configure the on-time and the interval-time via gui/hal

You can make "no encoder reset" & use standart linuxcnc homing procedure