Advanced Search

Ich versuche gerade eine while Schleife in einer while Schleife zum laufen zu bringen, die äusere Schleife wird nur ein mal ausgeführt,.

nc-code

F10000
#<radius> = 10
#<anzahlEcken> = 3
#<winkel> = [360 / [#<anzahlEcken>]]
#<verrundung> = 0.001
#<drehungUmC> = 60
#<wiederholungen> = 5

G10 L2 P1 R[#<drehungUmC>]
G64 P[#<verrundung>] Q0.0
#1 = 0
#2 = 0

o101 while [#2 LT [#<wiederholungen>]]
    o201 while [#1 LT [#<anzahlEcken> + 1]]
        g90 g1 x[COS[#1 * #<winkel>] * #<radius>] y[SIN[#1 * #<winkel>] * #<radius>]
        #1 = [#1 + 1]
    o201 endwhile
    #2 = [#2 + 1]
o101 endwhile
m2

ist es überhaupt möglich ?

Gruß
Rüdiger
 

I am working on integrating my first analog servo build. 7i97 and Anilam drives. I am following the steps here . I have the encoder scaling correct but when I go to enable the machine, there is a brief moment of runaway before I get two errors: 
"joint 1 following error"
"could not switch the machine on. is limit switch activated?"

I am only working on joint 1 at the moment. 
No limit switches are in use at the moment. 

I have tried inverting 'output scaling' and 'encoder scaling' in every possible combination on the configuration page. 

Any suggestions? 

Thanks! 

Do you mean 7I85 on P1 and PWM on P3  (on 7I76EU P1 is the first parallel expansion connector and P3 is the second)

Very interesting. A few points.
1. You don't say anywhere how to get the boards which are very well thought out. I'd love to test it.
2. New software to go into Master branch (2.10) which will be released in a few months.... This needs to be tested on this version (I'm finalizing a how to build linuxcnc video on my @MrRodW YouTube channel
3. Reformulate (or recreate) the git repo so this can be packaged as a PR to Linuxcnc. This would give you the best chance of success with your hardware project.
4. Your business model is similar to Mesa's so having an open source driver for your hardware in the Linuxcnc distro is not really controversial.

I revised the NC program and made the number of corners and the radius parameterizable.

Hi PCW,

I need custom firmware for 7i76EU with:
- 7i76 daughter card on internal SSerial (currently working)
- 7i85 encoder card on P2 (currently working)  
- PWM generator on P1 for 20kHz laser control



Can you create firmware combining all three?

Board IP: 192.168.1.121
5 axes: XYZAB vfd rs485 controls spindle direct on the mini pc with rs485 output

Thanks!

In linuxcnc 2.9.8 I genereted ethercat-conf.xml file from slaves with command:

That might be a question for Sorotec. They also offer grease guns and lubrication products, and should be able to make a recommendation:

www.sorotec.de/shop/Tools-and-utilities/...roducts/Lubrication/

HGH20CA is a Hiwin part number, although I suspect that Sorotec is selling generic clones. Hiwin has an extensive linear guide and ballscrew lubrication guide at the following link (737KB PDF). They recommend viscosity grade NGLI 2, and list specific greases (see attached table).

www.hiwin.com/wp-content/uploads/lubricating_instructions.pdf
 

Subject: Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Hi all,

I’d like to open a technical discussion about a project I’ve been working on, io_decoder, focusing on the software solution I've implemented to handle USB communication within LinuxCNC.

I am well aware that in the official LinuxCNC documentation and Wiki, USB is often described as 'the evil' (or, more formally, as 'not suitable for real-time control'). However, if one looks closely at the context of those warnings, they are strictly related to step generation and primary motion control, where microsecond-level jitter is fatal.

For HMI panels, MPGs, and secondary I/O, I believe this 'dogma' can be challenged if the HAL component is designed to manage the USB stack correctly. My goal is to allow users with complex retrofits (like those using Mesa 7i80/7i92) to offload all non-critical I/O to a single USB bus, freeing up high-speed pins and reducing the 'wiring nightmare' and EMI risks.

To test the limits of my custom HAL component, I’ve pushed it to handle real-time axis tracking via an encoder (not just simple buttons).

You can see the fluid response in this playlist: 
www.youtube.com/playlist?list=PL9D_TSVxg...tA9_k6njBeVTL0IYY7Ct

In other communities, the mere mention of 'USB' triggers an immediate rejection. I’m posting here because I’d like a more nuanced, engineering-focused feedback:

1. Given that a human operator has a reaction time of ~200ms, is a stable 20ms update cycle (50Hz) really a bottleneck for MPG tracking or HMI interaction, considering it's handled by a dedicated non-blocking HAL component?

2. How can I further improve the HAL component to make the communication even more robust against bus jitter?

The project is Open Source and I'm looking for peers to discuss the driver implementation rather than the hardware itself. What do you think about the responsiveness shown in the videos?

Documentation & Wiring: 
bobwolfrst.github.io/io_decoder-linuxCNC/

Best regards,
Roberto

So to use a custom panel you have made in Qt designer.
Say the panel name will be 'test.ui'
save the panel in your configuration folder in qtvcp/panels/test/ as test.ui

then in the ini under [DISPLAY]

EMBED_TAB_NAME=demo
EMBED_TAB_COMMAND=qtvcp test
EMBED_TAB_LOCATION=DIALOG

please give feedback on any problems or needs.

Chris

Ok it doesn't matter, this works in master or 2.9

Add the file to qtvcp/screens/qtdragon/ it will be in your configuration folder.
name the file qtdragon_handler.py

Then in your ini add this under the [DISPLAY] heading (this is an example):

# optional tab showing an external qtvcp panel
EMBED_TAB_NAME=Vismach demo
EMBED_TAB_COMMAND=qtvcp vismach_mill_xyz
EMBED_TAB_LOCATION=DIALOG

The key thing is the location: DIALOG will make the panel be a popup dialog.
You will see an arrow button show on the top right of qtdragon.
pushing it will toggle the dialog. There is also a HAL pin you could use to do the same.



 

I need a little guide on how to set up a tool changer. This is a new to me Okuma MC30-VA. I already have two machines running linuxcnc but both of them don't have tool changers. I'm aware of the carousel component but the way this is setup is kind of baffling.

 


1st issue is that the tool magazine doesn't have any sort of position sensors. No proximity switches. It's driven by an absolute servo and I think the tool pot position is stored as a rotary axis. so I need to put an absolute servo for that.

2nd one is the tool changer arm has an induction motor with a built in brake. it's kind of sticky and I think the brake is on it's way out. so I would like to put a servo for that too. Tool changer arm has 4 proximity switches (probably gray code)

I'm planning to use ethercat for this one and I think we can use 3 axis + 2 tool changer axis for this.
So how do I command these extra 2 axis with the ethercat. My initial thought is using them as two rotary axis with absolute encoders. But don't need them to be in the GUI. Can anyone offer some help?  

 

I forgot to ask if you are using 2.9 or master version? I have this working in principal in master branch.

Thank you for your suggestion automata, we are aware and taking into consideration all known approaches, bi-arc, spline, clothoids, quintic etc...
These are substantial changes which may need a separate branch, or a different planner again planner_type 2 or more.
As of now we are concentrating efforts on fixing the spikes that have been reported, and I've had some success, not ready to share the code yet, probably next week, but I will share a picture of my current results, I've used mainly Rüdiger's code for testing, but also Endian's and Peter's PCW. A special thank you goes to ruediger123 for making the simple rhombus code. I love it because it's very quick to test and shows the blending issues very well. This was the original code what is now in master linuxcnc running the rhombus with G64 p0.25 to accentuate the issue


And this is same code after some blending and cubic improvements, note that YangYang's code sp_scurve itself has not changes a single dot.
 
As I mentioned before the main issues were not in the scurve code itself but in the architecture around it that needed to be tweaked, or possibly be rebuilt ground up, but that's for another time.

As of  now the three big improvements/tweaks are:
1- making a bigger blending arc (still within G64 Pxx tolerance)
2- reduce velocity when blending (inevitable to avoid spikes)
3- limiting how much the cubic interpolation coefficient 'a' can change between segments - the cubic interpolation done after the kinematics was screwing up YangYang's smooth curves

Anyhow next week we are planning on refining and cleaning up the code, YangYang will work on tpOptimizePlannerMotions, I will do testing or real hardware not just scope reads, test latency as well. We may have a PR ready end of next week, but no promises.

I was also suspecting SPI is the issue, since as soon as I use SPI for tmc5160, The blinking LED which I configured to know if firmware is working, glows continuously insteed of blinking.
There is somthing different in ben-jecobson F4 port, since console output on uart gives garbage, no readable output.

As per your suggestion, I comapred both repos, for TMCsteppers both are same, no changes. And both F4 and H7 uses software SPI for tmc communication.