Advanced Search

Beware of changing cap types!

Multilayer caramics can change capacitance with voltage and stuff.

And ceramic caps are microphonic.

Tantalum caps don't degrade with age, only due to electrical abuse (which they are very suceptible to). (overvoltage, reverse voltage, etc.).

Read this before changing cap types: www.ti.com/lit/an/slva214a/slva214a.pdf

Thank you for your input, but at this time nothing I seem to do works out right. I clearly am missing something but I do not know what that might be. It's wonderful that a new version has a button for using a manual tool gauge, however after trying to follow instructions from this post - www.forum.linuxcnc.org/38-general-linuxc...-do-i-update-to-2-10 - and having the first two things fail with - www.linuxcnc.org bookworm InRelease' doesn't have the component 'master-uspace - I do not dare go any further as I do not want to risk what is working now. It took weeks to get the machine running and I do not want to have to start from scratch again. For now, I can at least set my tool height each time I change a tool by use a shim on the work piece top. A bit of a PTA but better than nothing.

Can't find anyone who can " translate" the procedure mentioned by the author into " human" language?
is this a script?:
sed -i 's/inm.00/inmux.00/g' ~/linuxcnc/configs/<config name>/<config name>.hal

Where should I put " pncconffor7i95T.txt" ?
what is meant <config name>/<config name>.hal
how do I run the script ?

Because Glade has a gui editor, vs hand coding xml files like PYVCP, I think it is best to just start playing with it. Load some of the demo sim configurations, then open those glade gui files using the Glade Editor program to get a feel for how those files are built and then make modifications of them. Then try to build your own VCP window.

The GladeVCP documentation really gives the impression that you have to build and do a lot with a Python handler file but you can do quite a bit without really needing much if any of one. However there is a lot more that you can do with Glade and a Python handler, that you could never even think of doing with a simple PYVCP gui. To the extent of even building an entire stand alone gui for Linuxcnc.

When i created this thread, i didn't know, where this 10 limit comes from.
Later i searched the servo drives docs and even found the limit mentioned there...
Will try to move some settings to SDO.
But its still annoying, because homing alone has more than 10 PDO parameters (eg speed, torque limit, time limits, etc). Many of them are somewhat just "nice to have".
But it seems, if i want to use them, i would need to switch ethercat-conf.xml (multiple times) during a linuxcnc program run. If that is even possible.
However in the near term i will go the simple route and stay within the 10 limit.

Not really interested to produce and sell.
Would take so much time, time I want to spend to make new things.
And it's not so unique, it's a remix of existing ideas.
Quite convenient though.
I don't mind at all if you sell units, will only help people.

Does axis jogging work?
If you issue an MDI command (eg 'G1 x10 f1000') do you get a ''Motor 0 Positionssfehler'? If so try to lower the feed rate (eg 'G1 x10 f10').

Impossible to troubleshoot further without knowing more about your configuration so post your hal and ini files.

Theese berger lahr drives are known for having faults because of the old caps. So I already have new ones at hand. Tantals for example will be changed to multilayer ceramics, but that is another story.

Yes, suprisingly theese machines were sold as engraving machines. Really beefy engraving lol.

But of cause I will install a spindle with more power. Nothing fancy for this project. Just a er25 4kW spindle and an old vacoon vfd laying around.

The PDO entries of the EtherCAT master are 128 in number. Any error will occur if the number exceeds this limit. For the same type of enumerated points, you can use the abbreviated form for writing. For example：<pdoEntry idx="6000" subIdx="01" bitLen="32" halPin="bit-in" halType="bit"/> Here, an input point with a sub-index ranging from 1 to 32 is declared.

Dear friends, hello everyone. Regarding this issue, due to the busy work, it has been a week since then. Currently, we have basically understood the problem. I extracted two different Ethercat master station data from Wireshark and conducted a comparative analysis. From it, we can see that the entries of the PDO have a slight difference in the arrangement order. The main difference is reflected in the two special status words, namely " {0xf200, 0x01, 16}," and  {0xf100, 0x01, 16}. We are currently in contact with the manufacturer to confirm these two PDO entries. These two entries are used for a special design. Additionally, there is a problem with the parsing data of the data sent from IGH to PDO by the IO module!

After a long break I'm back to the topic. I did some research, tried to swap the wires between the mesa and the servopack, but no changes. It's not a problem with the analog voltage as in the topic because if I set P=0 I can normally drive at high speed without a closed loop.
What should the encoder accuracy be set to?
Maybe I have set the scale too large or too small?
But I tried changing it to less and it didn't have any effect.
I'm still wondering if the analog wire can go parallel to the encoder wire, maybe it creates some interference.

Hello do you mean that instruction:
Simple Remote Pendant using a $10-20 joypad with halui and hal_input
???
The .zip downloadlink sdly doesent work anymore.

I use analog jog on all three of my machines with 2.9.4. Quite a while ago, I updated the wiki for remote pendant including .hal files you can include.

langdons wrote:

You don't need to make a custom keyboard, a standard keyboard has losts of "useless" keys which you can repurpose for your needs.

 

"Need" has nothing to do with it.  GUI's and physical interfaces are deep in to the realm of personal preference... so there is no right answer for everyone.

If a body wants a user interface - screen and physical - which mimics typical industrial control panels then there is a certain layout, workflow, and feature-set they're likely to prefer.

I suspect that repurposing some keys on a standard keyboard is unlikely to tickle thier fancy.

Of course, everything I've posted above is based on my own preferences regarding CNC interfaces.

langdons wrote:

My Bosch cooktop freaks out with a drop of water; it's really annoying.

AFAIK, touchscreens basically work by detecting the water in your fingers (fingers, like most of the body, contain lotsa water); so actual water can triggger them.

However, water will likely break a mechanical keyboard/switch if not dried promptly.

(Membrane keyboards are probably fine.)
 

Resistive touchscreens have an outer flexible panel, a sheet of invisible contacts, and an inner glass layer.  When you press the outer surface the contacts in that location are physically closed and the computer registers a touch.  They generally can't do multi-touch, but they do work with gloves of any type and require a firm enough press that anything bouncing, hitting, or splashing on the screen is unlikely to activate it.

The other nice thing about resistive screens is that you can tape a sacrificial piece of clear plastic over the top to protect it.  Once that gets scratched or dirty, replace... and the touch function still works.

A membrane keyboard is certainly water/coolant resistant, but even if the contacts are rated for a billion presses the overlay wears out and then the whole thing is junk.  Also they may not have a great tactile feel, especially for typing.

There are some rather good waterproof panel-mount keyboards available these days, either from ebay or Aliexpress. Many configurations - with/without touchpads or trackballs, stainless fronts, different key combos.  The one I got recently has a stainless face and keys, but the actual tactile switches are under a continuous sheet of rubber - no water ingress.  I wouldn't want to type a novel on it, but it feels quite good for a very robust keyboard.

I have Cherry mx keyboard switches on my mill control panel and have had no issues with coolant or chips damaging the switches.  Unless the switch panel is horizontal (or nearly), any liquid splashing on the panel is likely to drain down before it gets to the switch contacts or mechanism.  What kills mechanical keyboards is dumping a quart of sugary soda on them until the mechanical bits are submerged and they get glued in place.

The proliferation of people making a living banging away on keyboards means there's been an explosion of mechanical keyboard parts, instructions, and related stuff available for a few years to consumers:

• Sockets for Cherry mx-type switches that solder to a perf board.  Meaning if a switch fails it's extremely easy to replace.
• Clear switch caps for inserting your own legends
• Multiple switch 'feel' varieties
• Aftermarket springs to stiffen up the action (even the stiffest 'stock' switch feels pretty limp compared to industrial pushbuttons)
• Vendors eager to machine/cast/print custom buttons
• Online keyboard layout generators with standardized key spacing and templates