Advanced Search

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

PCW wrote:

I think the potentiometer is being used as an absolute position feedback device.

(probably meaning that the long shaft only turns a few times)


 

+1

guys, a littlebit of play with the design is get the ninja look.

 

I think the potentiometer is being used as an absolute position feedback device.

(probably meaning that the long shaft only turns a few times)

 

Kieran wrote:

yeah touch screen would work. But what happens when some drops of coolant hit it and it freaks out. my phone is bad enough with a tiny drip of water. I wonder if itd be worth making a custom keyboard and special mapping some keys. QTdragon looks nice. I may give it a try. 
 

Look for a resistive touch screen.  They're a little harder to find nowdays, but they are significantly less likely to trigger from a drop of coolant, errant fly, or other unintended activation.  Downside is they're a little scratch prone and aren't as bright or crisp as the more modern touch tech.

There are no 'industrial' GUI's currently available which mimic Fanuc or Haas interfaces.  The closest I've seen is an unreleased GUI a gent teased the forum with a couple years ago.  He mentioned that he might make it available to the LCNC community, but I suspect he's got enough work in to it that he (or his company) want to keep it to themselves.

forum.linuxcnc.org/show-your-stuff/47118...ing-some-work#254061

Another close GUI (in my opinion) was "Hazzy", but that's been abandoned for quite some time and won't work with current Linux or LCNC versions.  You can find archived Hazzy stuff on github and searching the forum for screenshots...even if only for ideas.

Gmoccapy is pretty close to commercial GUIs in concept with the bottom/side-row softkeys, but there are some features/quirks which deviate from my experience with commercial offerings.

Touchy has no on-screen jogging (nice) and is, I believe, designed for use with hardware controls.  But it's a little dated or sparse for some tastes.

With a bit of effort, however, you can get close(ish) without having to create a GUI from scratch.  Here's a shopping list of user-possible modifications which can make a GUI more commercial-feeling:

• Eliminate mouse
  • resistive touchscreen
  • trackball/trackpad in a panel-mount keyboard
• Dedicated hardware CNC function keys
  • Using a Mesa 7i73 and matrix keypad you can have (up to) 64 hardware keys programmed to do whatever you want.  Keys need not be physically in an 8x8 matrix - just electrically.
  • With some relegendable buttons or keys and a 3d printer you can create a CNC panel that's very close to whatever flavor Fanuc/Haas/Siemens you want.
  • There are plenty of other ways to get dedicated hardware buttons, but using the 7i73 means no USB latency and it's very easy to configure.
• Eliminate keyboard & screen-based jogging/motion
  • Most GUI programs have some ability to edit or restrict keybindings - it's just not obvious without digging.
  • Eliminating on-screen jogging is much harder - that takes editing the interface, although the QT-based screens make it somewhat easier.
  • Be prepared - getting rid of anything on every screen/tab which can cause motion is a monumental effort.  And even when you do get rid of everything, LCNC still doesn't behave like commercial controls.
    • On every commercial control I've used, the machine will not move unless you press cycle start (aside from hardware-button only jogging).  Probing screens, MDI, tool changes, everything... you must press cycle start to make the machine do something.
    • LCNC's ability to accept commands from external sources (python, GUI's, etc) means a GUI author can put a "G0 Z-infinity" button everywhere they want... and pressing that button will make the machine move.
• Look for a GUI which works with a 4:3 or 5:4 monitor
  • Most commercial GUI's aren't using wide-screen formats, so they don't try to fit everything on a single screen like most 16:9 LCNC GUI's do.  You may be more comfortable with a smaller real estate monitor and more screens to flip through... keeping the essentials on the main page.
• Tooltable
  • I don't know how to modify all LCNC GUI programs, but I know the QT and QTpy based ones can be modified as to which tool table columns are displayed.

The downside to creating or modifying a GUI is that updating LCNC or the GUI becomes tricky.  And creating a GUI from scratch is a monumental effort.

Hope that helps a little.

Hello everyone,

I need your advice on an industrial embroidery machine.
I've managed to recover a Toyota ESP embroidery machine, but it's broken down to the level of the electronic board, I have the impression that it has lost all its parameters, there's a ‘-’ on the screen and then nothing.

I'm going to retrofit it and drive it with linuxcnc.

Following the dismantling of the casings, I have a few questions:

-1: I have a DC 30W servomotor with 500 pt encoder in single ended 5V. and at the end of my axis I have a Copal JC30S potentiometer. Does this potentiometer correspond to a tacho (speed control)?

 

 

 

-2 : On my motor, the maximum voltage is not indicated. To power my machine, I use a power supply that mixes 5V and 24V DC. I assume that its motors are powered by 24V DC, correct? Do you know of any DC driver references for this motor power with tacho (if the potentiometer has one) 

 

 

I built a few panel using the PYVCP approach, it it seems OK for displaying values but not so good for changing them (e.g., disabling an axis). I think I will need to make the jump to using the GladeVCP, but the manual seems a bit tougher to use for that.  Are there any good references I can use to get started with using Glade?

In that case you would need

5i25t_7i77_7i74d.bin

firmware

 

I think I am getting this figured out. I am pretty sure with the loadrt mh2_pci I see it mention the 7i77 now so that should be working I just need to get it to serial mode 3. I also need to figure out how to make the 5i25t communicate with my 7i74 which will be hooked up to the 7i84 and 7i73

The LY mill has 300 (X) by 400 (Y) mm travel and about 180 in Z. The overall machine is 1000 mm deep, 600 wide, and 600 high. Weight is 375 kg.

Re-capping a few boards seems manageable. There is less patience for old electronics. I think it reflects a lack of widespread electronics knowledge.

That PC stand is something else.

These were sold as engraving machines. I assume a spindle/VFD upgrade is in order?Will you be doing anything beyond aluminum?

Are you saying you do not get a consistent velocity reading
when the encoder is being rotated at a constant rate?

 

System:

• CNC lathe with X and Z axes, stepper motors, Mesa 7i96S
• LinuxCNC 2.9.4, config generated by PnCConf, then manually edited
• Logitech Dual Action gamepad via hal_input (-KRAL Dual)
• GUIs tried: axis and gmoccapy, no difference
• Goal: proportional jogging (analog, stick halfway = half speed)
• Only Z axis motor is connected, X is not connected at the moment. Jog via GUI (mouse) works fine.

Symptoms and troubleshooting so far:

• Gamepad is detected correctly (evtest, halmeter both show correct values).
• In halmeter/halshow, input.0.abs-x-position and input.0.abs-rz-position change smoothly with stick movement. Scaling set so left = -1, center = 0, right = +1.
• Connections in custom.hal: net jog-z input.0.abs-x-position => halui.axis.z.analog and the same for X.
• The analog pins halui.axis.z.analog and halui.axis.x.analog show the values in halmeter.
• Jogging with GUI works, motors run as expected.
• If I jog with GUI and simultaneously move the stick in the opposite direction, the axis stops moving. This proves the analog value reaches the right place.
• No matter the scaling (tried 1, 127, 32767, etc.), values are correct in HAL but motors do not move from analog stick alone.
• I have NOT tried digital jogging via button/plus/minus, as I only want analog.
• No hardware issue: GUI jog moves motors.
• Estop, enable, limits, homing are all checked and fine.
• All HAL pins/signals seem correct, no missing values.
• No difference with gmoccapy GUI.

Relevant config snippets:
custom.hal:
loadusr -W hal_input -KRAL Dual
net jog-z input.0.abs-x-position => halui.axis.z.analog
net jog-x input.0.abs-rz-position => halui.axis.x.analog369.hal:
net jog-x-pos halui.axis.x.plus
net jog-x-neg halui.axis.x.minus
net jog-z-pos halui.axis.z.plus
net jog-z-neg halui.axis.z.minus
net jog-selected-pos halui.axis.selected.plus
net jog-selected-neg halui.axis.selected.minus
net jog-speed halui.axis.jog-speedini:
[HAL]
HALUI = halui
HALFILE = 369.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal
[KINS]
JOINTS = 2
KINEMATICS = trivkins coordinates=XZWhat I have tried:

• No hardware issue: GUI jog always works, signals are visible.
• All estop, enable, limit and home inputs are OK.
• No errors in logs, no HAL load error.
• Both axis and gmoccapy GUI tested, no difference.
• Analog pins connected, values update, motors do not move via gamepad.
• All possible scalings tested.
• Did NOT try button jog (digital), only want analog.
• It feels like halui.axis.*.analog is either not "active" or some enable/select/mode/condition is missing, or maybe a bug in halui or GUI blocks analog jogging.

My questions:

• Is anyone currently using analog jogging with hal_input and halui.axis.x.analog etc. on LinuxCNC 2.9.x? If yes, what is the minimal working config (enable, select, mode...)?
• Does analog jogging need a special enable/select/mode pin to be set?
• Are there known bugs or dependencies in halui/axis/gmoccapy that block analog jogging?
• Can anyone provide a minimal working config for analog jogging?

More info or logs can be posted if needed.
Thanks for any ideas!

Hello i have conect a china optical enoder with 1024 steps today on my lathe and mesa79i6s
have set up with 4096steps i get velocity from 6-10 thats way to different or?
What i make wrong? i looking for threadcutting in future
Thanks

I haven't tried any other program. This was my first test and I made it as basic as possible.
Could there be something in the .hal or .ini that makes it expect relative positions?
What information do you need?

It looks like you have the host IP address set to 192.168.1.121.
This will not work, you need to set the host address to something
different but in  the same network range, say 192.168.1.100

(in other words, you were not pinging the Mesa card but rather the host itself)