Physical Control Panel Feedback Wanted

rodow

my problem is about correct sequence in no gui mode, modbus command, halui interface + motion command ... I find that: someone the normal sequence is right sometime not .... sometime I bring the messages warming "not possible ......" from teleop to mdi and from teleop to auto ... because there are some delay .... where it is I not know ... so I must study better the various sequence style (actually I use a solution post some year ago from BigJohnT) because the modbus delay I think, broke the sequence ... in order to realize a test sequence to the delays generated by the modbus. Today I do not have time .. I do it next week. Thanks for the link I'll study.

Giorgio

Georgio,
Yes I plan to use an Arduino to monitor the buttons. The arduino is connected via modbus. A heartbeat signal will be generated on at least a bit. In RTAI, if the bit does not change for ~200ms the machine will pause and indicate an error. It will not be realtime, but I think it will be fast enough.

I just had the idea of having the maximum machine velocity setting on a knob would probably be VERY useful, as it limits both the rapids and the programmed feed movements. It also seems to me that feedrate override and spindle override should probably be encoders, too. Otherwise, I fear they may fight some settings from the pendant or the UI and when i power on the machine I will have more things I have to tweak before I can start using it. Thoughts?

Up for comment, R3 of the Physical Button/Knob Layout

Revisions and why:
Pots mostly converted to encoders to prevent fights with the Axis UI. Same for going to PB's for the Jogwheel function.
Buttons placed above feed hold for single stepping.
Added TABLE MAX SPEED because that is what I really am trying to limit much of the time I might be reaching for feed override.

I would avoid any pot's. I built my physical panel using pots and have since ordered encoders [with center press button] to replace them. I do not like anything absolute and prefer relative "knobs". Since any small changes will cause changes to the gui, as you mentioned causing a fight between the two. [the intent of push button is to sync to 100%]

I haven't the time to install them as of yet however.

One button I found that i used a lot besides feed/spindle override is a start/stop button. I used one button to do both inputs. I use that one button -almost all the time.

Thank you to everyone for the input. I have built the physical button panel and mounted it on the machine. It is shown in the attached. Labeling, painting, and wiring is yet to be done. More info at sites.google.com/site/yeltrow/shizuoka-a...-linuxcnc-conversion

very nice ... bravo!

regards
giorgio

Thanks! All the code I used is in my github repository: HERE My current setup consist of all the buttons connect to an Arduino Mega 2560. The Mega 2560 is connected currently via USB (as ttyACM0). mb2hal communicates to over the USB connection and makes pins for hal. I pass the packed bytes into a component I wrote called hwpanel.comp. It just remaps the 16 bit groups into 32 bit groups for the encoders and breaks out the individual button lines so hal can get at them easily. The arduino code, theshiz.hal, theshiz.ini, and hwpanel.comp are all in the github repo.
My current issues are:
1) Pause/Step/Run/Stop/Feed Hold work kind of weird right now because of the pins they are mapped to and how I thought they worked. I'm going to get them straightened out, but for the time being, the feed hold does stop the feed, stop stops the machine, and after that things get weird... I working through it.
2) I am attempting to use acceleration on the jog wheel. It can surprise me from time to time and needs work.
3) The momentary buttons for selecting different axes to jog haven't been connected in hal yet. Feed override works fine.
4) Spindle Override is yet to be done.
5) I have no idea how the direct entry input stuff works to connect the potentiometer for max speed into halui....
6) Coolant and spindle control buttons aren't wired into hal yet.
Pictures and details at my website.

Yikes - Watchdog time.

I had an episode this morning where I think I broke the USB connector on my Arduino mega. This highlighted the need for a watchdog.

The solution I came up with for monitoring the communication health of the Arduino on modbus is to output a bit to the Arduino and have it echo the bit back. The hwpanel.comp component I wrote that separates out the bits that come packed as a 16 bit integer does the dirty work of inverting the bit and sending it back to the Arduino again. This causes the bit to become inverted every pass through the Arduino. If the loop fails, the oscillations stop. The oscillations are monitored by the hal watchdog component. If the component does not see an oscillation every 600ms, it triggers a message and the halui.machine.off bit. This will cause the machine to stop immediately and will prevent it from operating if the machine powers up and can't communicate with the front panel. Anyone have a simpler or favorite way they accomplish this? The code for hwpanel.comp and the arduino are in my github repo.

loadrt watchdog num_inputs=1
loadrt not names=not-estop,not-watchdogok
loadrt message names=msgwatchdog messages="Button_Control_Panel_Watchdog_Timout "
addf watchdog.set-timeouts servo-thread
addf watchdog.process servo-thread
# HARDWARE BUTTON PANEL WATCHDOG
setp msgwatchdog.edge 0
setp watchdog.timeout-0 0.600
net hwpanel-heartbeat hwpanel.0.HEARTBEAT watchdog.input-0
net msg-hw-panel-wd watchdog.ok-out msgwatchdog.trigger
net estopreset not-estop.in
net estopreset-not not-estop.out watchdog.enable-in
net mb2hwpanel8 hwpanel.0.reg8 => mb2hal.RegOut.00
net msg-hw-panel-wd not-watchdogok.in
net watchdogfault not-watchdogok.out => halui.machine.off
addf not-estop servo-thread
addf not-watchdogok servo-thread
addf msgwatchdog servo-thread