ks14 project is not dead

Looking through old posts I see i started my ks14 project in 2012. I wasn't excited about the rf module mounting setup back then and have been working towards being able to machine up some real RF cavities (or at least "RF-cavity-like") parts.

At this point in my DIY Mill project and after implementing Yuriy's TouchDRO on it, I think I'm finally ready to do it right.

Here's a 3D model of the part I need to stack 14 of the USB RF Modules together in a single solid block:

ks14 rf cavity dimensions

Here's the USB RF module that will sit in the cutout:

Stacking those cavities up should make a nice package of Wifi radios. I'll make a couple one sided cavities for the top and bottom covers of the stack and connect them all to the RX splitter already detailed in old posts.

I still need to work out how I'm going to wire up the USB, but I'm pretty sure I'll be gutting the USB hubs I had planned to use and wiring them in.

Hopefully this weekend I'll mill out the first cavity, get things adjusted so the module fits nicely and have the ks14 project back on track.

Investigating/Fixing HP ILO2 Java Remote Console fails to start with Class Not Found remcons.class

TLDR; Just give me the new fix

This made things work for me when put together with "Stuff Everyone Has Already Done" down below. Uncheck Use TLS 1.1 and Use TLS 1.2 in Java Control Panel, Advanced Tab:

Be sure and close all Firefox windows and restart the browser so that change takes effect.

Also, make sure and run the remote console twice (to the same ILO server) before you consider it not fixed. I'll explain that 2x run thing down below, but essentially on the first run, the remcons class jar file gets cached but NOT used and the next run it actually gets used.  For some reason it will only run "from cache", if that makes any sense. It's like old routers that could run from RAM vs run from FLASH, in this case run from CACHE :)

Troubleshooting Tach stability with new VFD addition

I got my VFD added to the non-milling machine. The first thing I noticed was that it worked :)
The second thing I noticed was that my RPM readout was all over the place (800-2200 @1550RPM actual).

After alot of troubleshooting, it turned out to be my cheap "DVE" 12V power supply running the Arduino was entirely the problem. I discovered this after I tried a battery in place of the Arduino power supply.. and then tried another power supply.

Luckily I found it pretty quick but for people having trouble with their DIY tach sensor circuits and readings, keep my experience here in mind.

VFD Addition to My non-Milling Machine

Since I have installed the tachometer on my TouchDRO setup, I have no choice but to convert my non-milling machine to variable RPM with a VFD (and as I found out, a 3-Phase replacement motor).

With the VFD you can get more than just speed control, reversing, jogging, ramping up/down, increased torque at low speed, blah, blah, blah. There are tons of video's and posts all over the internet of DIY projects using VFD's on various machines which taught me what little I know about them.

VFD

The Teco EV Series (similar to older FM50 series)has many examples of DIY usage on Youtube, so it was sort of the natural choice. I did look around and almost bought one of the new Weg CFW100 Series. Both had V/F and "Sensorless Vector" modes, digital inputs etc. but the configuration software looked a little more impressive on the CFW100 line.

In the end I found a good price on the Teco EV model I needed and decided to go for it. I also got the RS232 plugin and I'm hoping the RPM can be set via RS232 in any future CNC setup I do.

Motor

The VFD is designed to control a three phase motor. That's just how they work. There is such a thing as one that controls single phase motors, but they supposedly don't do much beyond speed-control. So I had to find a replacement for the existing single phase 1HP motor.

I found that I wanted an "inverter duty" motor which seems to primarily mean that it has a high temperature Insulation Class rating like "F". At low RPM the fan does not cool as well, so it's running hotter than it would at the rated RPM. There's also some magic done by the VFD to increase low speed torque(among other things) which makes it run hotter.

With the low duty-cycle manual drilling/milling operations I'll be performing I doubt it would heat up much. Although, if I ever get steppers installed and can run CNC operations it could stay on for longer periods.

Anyway, I picked out this Dayton 1HP 3PH motor. I get a large discount and no shipping cost on it so it's pretty much the cheapest 1HP 3PH I could find (other than well worn used ones).


It's all on order now, hopefully it will come in before this weekend.

P410i firmware update from Centos on HP Proliant DL360 G6

As of this posting, as far as I can tell from digging through hp.com, if you want the latest v6.60 P212, P410, P410i, P411, P711m, P712m, or P812 Storage Controller firmware updater for Linux:

1. It's only available for 64bit
2. It's only works with the cciss driver.
3. It's here CP023866.scexe

I got obsessed with updating a DL360 G6's P410i firmware before making a RAID array and installing Centos 7.

TouchDRO setup completed

Well it took way way longer than I planned, but I finally completed the setup of Yuriy's awesome TouchDRO software and hardware on my non-milling machine..

Yes, it's a drill press and I know "you can't use a drill press as a mill". I already covered that here.

gpsd stdout stderr silently killed by SELinux on Centos 7

Setting up gpsd with a new gps device, I usually run gpsd in the foreground with debug output so I can see if the gps is detected.

It looks like something like this:

[root@octobox3 gpsd]# gpsd -D99 -n -N /dev/ttyS0
gpsd:INFO: launching (Version 3.11~dev)
gpsd:IO: opening IPv4 socket
gpsd:SPIN: passivesock_af() -> 3
gpsd:IO: opening IPv6 socket
gpsd:SPIN: passivesock_af() -> 4
gpsd:INFO: listening on port gpsd
gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: successfully connected to the DBUS system bus
gpsd:PROG: shmat() succeeded, segment 131076
gpsd:PROG: shared-segment creation succeeded,
gpsd:INFO: stashing device /dev/ttyS0 at slot 0
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyS0'
gpsd:INFO: speed 115200, 8N1
gpsd:IO: => GPS: $PASHQ,RID*28\x0d\x0a
gpsd:IO: => GPS: @F0.3=1*67\x0d\x0a
gpsd:IO: => GPS: @F0.3=1*67\x0d\x0a
gpsd:IO: => GPS: @F2.2=1*64\x0d\x0a
gpsd:IO: => GPS: @F2.2=1*64\x0d\x0a
gpsd:IO: => GPS: GPS:GPGGA 1\x0d\x0a
gpsd:PROG: writing oncore control type Cj
gpsd:IO: => GPS: @@Cj)\x0d\x0aRID*28\x0d\x0a
gpsd:SPIN: open(/dev/ttyS0) -> 6 in gpsd_serial_open()
gpsd:PROG: Probing "Garmin USB binary" driver...
gpsd:PROG: Probe not found "Garmin USB binary" driver...
gpsd:PROG: Probing "GeoStar" driver...

So when I installed gpsd from EPEL on a Centos 7 box the other day I was surprised that running gpsd would not produce any output. even "gpsd -V" would not show the version number. I strace'd the gpsd -V run and could see that the write() to STDOUT (file descriptor 1) was actually going to device 1,3

fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7e13b4b0) = -1 ENOTTY (Inappropriate ioctl for device)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa1e9502000
write(1, "gpsd: 3.11~dev (revision 3.10-5."..., 55) = 55
exit_group(0)                           = ?
+++ exited with 0 +++
[root@octobox3 gpsd]#

 Device 1,3 is /dev/null

[root@octobox3 gpsd]# ls -l /dev/null
crw-rw-rw-. 1 root root 1, 3 Dec 22 00:20 /dev/null

I searched /var/log and poked around in systemd (disabling gpsd, gpsdctl etc), journalctl etc. I ended up rebuilding the RPM and installing it... same problem. I built from the source tarball and ran the resulting executable... now it works!

So, I copied it to /usr/sbin over top of the existing /usr/sbin/gpsd. Didn't work again! After a few more cp+mv tests and rebuilds and it finally occurred to me. That the "copy" to /usr/sbin/gpsd resulted in the same permissions and SELinux contexts/attributes being applied to the file.

At this point I was convinced the problem was due to the SELinux context of the gpsd executable installed by the EPEL rpm. Googling this new info led me to this blog post.

In that post Dan Walsh explains the whole situation, including the fact that the tty restrictions are usually set by default to NOT produce an AVC message so you see nothing in the logs (and have no idea what's going on if you've never seen this before).

He also gives a solution:

setsebool allow_daemons_use_tty on

That will temporarily allow any daemon that is normally restricted from accessing STDOUT etc to actually use STDOUT. It won't survive a reboot in case I forget to set if back off, which is preferred in this case.