Advanced Search

Just to close this topic down, having found the enthusiasm to strip the machine down...

So, it looks like every group of 8 inputs is routed through it's own octal analogue mux, with each input circuit comprised a current limiting resistor, a pull-down resistor (essentially a voltage divider) and a capacitor snubber.

That only one input is at fault suggests either the mux (LV4051), or the RC network on each pin, or the pin itself. I've examined under magnification all joints, and reflowed them all, and the problem remains. Therefore I conclude the most probable fault is on the mux, most likely due to user (my) mishandling,

At this stage, remapping the input to an otherwise unused input closes this problem - tested and proven. I thank you all for your earlier replies.

This is on Mint 22.3 with Mint-L-dark theme, notice the text on the left is clearly visible, on any other black theme no text can be seen there.
And this is not limited to LinuxCNC, many other programs i use daily had the same issue before so i had to revert to bright themes when using them.
What GUI are you using?
I know Axis can be modified, and so can the QT versions.
You can also try to install Mint themes in Debian, or Ubuntu themes. See also Ubuntu Studio as they do have some very nice themes, but forgot what they use as DE.

I have a silly question: how do I install this version to replace the original one that comes with LCN?

Changing any of the colors in Debian settings has no effect on the editor in linuxcnc. That's why I'm here.

1. that is not a LinuxCNC issue, so Debian forums are a much better place to ask
2. i had the same issue on Linux Mint when using the included dark themes, but 22.3 added new dark themes that fixed the issue.
3. you can try fine tuning colors for the dark theme, for text mainly as that worked on Mint so should also work on Debian.

I'm having an issue that I couldn't find a solution that worked. I prefer Adwaita Dark theme. Everything is fine that is when I go to edit a gcode file in linuxcnc, the text highlight washes out the text. See image: 


During my search I have found a script to add to the user command file, it just seems to crash when it tries to load. I have attempted to change the editor in the INI from gedit to mousepad, heck, I can actually leave it blank and it still changes nothing. I have changed the theme to use the system settings, still no change. The only way I can get this to where I can read the highlighted text is to change out of dark theme which isn't ideal. I'm sure there's a solution, I just haven't found one that works. Anyone else find a fix for this?

Indeed, with Linuxcnc version 2.10, the HAL Bridge works and the Bridge pins now appear. Interestingly, in the QTDRAGON configuration examples, the macros and MDI-Command-macro are defined in the ini file, but the instruction HALBRIDGE=hal_bridge is not defined in [HAL]. It would be good to update the configuration to include it.

Not long ago I finally got some down time with the machine and dug into the issue I was having. I'm posting this for anyone who might have a similar issue of strange happenings where it'll act weird on the first run then act fine after or act fine on the first run then act weird on the next.

This is how I found it: We got a new job and I was programing a radius cut for football shaped rollers that go into omni wheels or mecanum wheels for a robotics company. When I started the program it would follow the radius on the first pass just as programmed, although way too fast. The exact issue I had before. But this time when I ran the same program again I got a warning saying "current point same as endpoint of arc" this told me I lost or had conflicting gcode in my preamble. Namely G18 which is used for circular interpolation needed for a G2/G3 arc. So I started digging into my .INI file and there was a line called [ RS274NGC_STARTUP_CODE = ] Here was string NC codes that conflicted with the preamble I had in the program. I removed these and the problem completely vanished. No more racing on first run, no more weird errors. I hope this helps others who maybe having a similar issue. 

Hello.
Recently I ran into an issue with adding in a z probe for automatic tool touch off for a newly built CNC using a mesa 7i96s. After running I get an error "halui.mdi-command-00 does not exist". I have attached my config files. The only line in my postgui file is as follows (so I dont have to attach it)

net ztouch halui.mdi-command-00 <= pyvcp.ztouch

Any help would be greatly appreciated. Thank you!

-Nick 

 

I don't think there's standard firmware for that

Do you need DIR signals with the PWMs?

Do you have a preferred pinout?
 

Hi PCW,

I am looking for a custom firmware for my Mesa 7i95T board. I would like to have 4 PWM generators available on the P1 expansion port. 

Could you please provide a bitfile (and XML) with this configuration ?
Or let me know if such a configuration alredy exist in the standard support library for the 7i95t.

Board: Mesa 7i95t (Ethernet)
Requirement: 4 PWM outputs on P1 connector.

Thank you in advance for your help!

or I might just have wasted a bit of time, making an option no one wants, it happens...

Sometimes it just takes time for a new feature to land with users. It is usually good practice to follow the implementation in other controls, so your solution is probably fine.

M27 is wrapped_rotary but allow values ​​>360 , on which modulo 360 is done.

M26 is just shortest path, have to split any rotation >=180

My reasoning to have M26 is default, was because gcode with short segments you can run them with less post processing tricks, I thought. Also other controllers seem to have this as the default.

I did not want to change wrapped_rotary because it's already an option that is in use, rotary_modulo was more descriptive of the functionality, and maybe in future this option could replace/supersede wrapped_rotary, wrapped_rotary=2 could work, but for a first draft and testing purposes I went for rotary_modulo.

I could have M27 as the default behavior, don't think it matters much, it's more about preference.

I understand that for who already has figured out wrapped_rotary then rotary_modulo doesn't add much, and for who does not want to touch the post, neither are viable, but I think if you were to start from scratch, and you were willing to tweak the post, you'd reach for rotary_modulo rather than wrapped_rotary, or I might just have wasted a bit of time, making an option no one wants, it happens...

I'm not really in a position to do any testing on hardware right now (I no longer work in a router shop.) but I can offer links to some G-code that I used in the past to help with testing the circular arcs tool planner when it was being developed. They are some 2.5-D V-groove engraving tool paths. They are in inches and need to have approximately +/- 0.003 of precision in the movements to look good. The first file is only XYZ moves, the 2nd file has XYZW to run a 2nd engraving spindle on a 2 headed router.

 

​​​​​​​ 

djdelorie wrote:

As the originator of this request, I've left my feedback in detail elsewhere, but let me summarize my request for this thread: After an hour or more of spiral carving with Fusion's linuxcnc postprocessor, I end up around A556200 (for example), then Fusion does G0 A0 to "reset" the rotary for the next op.  That takes many minutes of high speed spinning, and is totally unneeded.  I would like to skip this massive unwind.  This is a common complaint online, and the usual response is to use G10 to change the WCS offset before the G0 A0 but that has its own drawbacks.  Doing something similar in the G0 itself would be much more consistent across the machine's operation.  Yes, WRAPPED_ROTARY, but there are times when you don't want to use that.
 
 

Don't expect the standard LinuxCNC postprocessor in Fusion360 to be 100% compatible. It was created by people unfamiliar with LinuxCNC and who don't respond to error reports—this is a common problem with some basic HSM posts. This is especially true for the LinuxCNC post for turning—it's completely unusable without modification. 

To work with the WRAPPED_ROTARY function, the post needs to be modified so that the A-axis output is in the range 0-360 and the sign indicates the direction of rotation.
If you can't do this yourself, I can help with instructions later.

grandixximo post=346054 userid=3182
What I want to hear: does this behavior fit how your CAM emits G-code, would M26 default plus plain absolute output Just Work for you or would you need M27 sections, are there kinematic configs (coupled 5-axis TCP, gantry rotary, weird mappings) where you think this would behave badly, and do you have test G-code you would like me to run through it before merge.

Most CAM systems support any logic, but this needs to be configured in the post. This isn't done by default.
In any CAM, the postprocessor requires settings specific to the specific system. The fact that some users experienced problems with the rotary axis returning to 0 only means they didn't configure this setting and were using the wrong postprocessor. Having done this, there are no problems working with the current logic.

Regarding changes, I think the ideal change would be to simply add the ability for the WRAPPED_ROTARY function to automatically handle values ​​>360 in absolute mode.
However, giving users the option to toggle is also a good option.

But I don't understand the difference between m27 and the current wrapped rotary mode; as far as I understand, they are identical. Perhaps in this case, adding another INI line isn't necessary; adding wrapped_rotary=2 (type=2) will suffice, which will set the default mode for the rotary axis (m26 or m27).

I also believe that M27 is the primary mode for operation.
Reducing all transitions (in m26) is difficult to debug and lacks the ability to strictly define the direction of transitions >180.
Most 5-axis mechanisms don't have infinite rotation capability, and this is critical for them. Otherwise, additional functions have to be added to the post to separate movements >180 into two separate lines - that's an additional overhead.

Also, incremental mode is not recommended for use in CAM—it's prone to error accumulation during multiple short movements, which is what most programs consist of.