Advanced Search

Just to close the loop on this from a Teknic/ClearPath perspective, they have a Jitter delay that can smooth out motion, that was set at 14ms, when turned off the f-error dropped to 2ms which is in the ball park of a timing loop. 

Long story short, I am turning off everything PID related since I am using CSP and DC as long as my jitter setting is the same on all the motors they will all end up at the same commanded place at the same commanded time even if LinuxCNC is 2ms behind. 

Hello.
I had to recreate LC10 homing code from zero reading manual designated for a driver with a motor with incremental encoder . ( I thought original code was difficult to fix )

If you still have some problems, I consider to open my codes...( I have something to do for some improvement )

The zswap fix seems intended to fix a system log error message "Failed to start zramswap.service" but I checked systemctl and have no failed units, so it doesn't seem relevant to this case, is it?

Is there a guideline on how much memory to allocate to the GPU? This is a 4GB Pi 400. One idea I have is to compare the config.txt with that of other images that work well.

The other thought is regarding codecs or configuration that may be missing as suggested by the attached report from the chrome://gpu

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: