I spent a bunch of time getting to the bottom of my MDX-20’s self-destructive nature. After a few hours of experimenting, I ended up in a hair-raising situation!

Trace files gave some unexpected results and I feared that I may break a collet. I knew there was some kind of pattern to the results.

One possibility that I investigated was old milling jobs filling up the queue between my computer and the MDX-20. I noticed that the “Modeling” light was flashing rapidly.

After some research, I tracked down the Modela software that I thought I needed. I installed and ran the apps on Ubuntu through Wine. Still, I was only able to send jobs up to 6% of the way before the machine turned erratic.

I sent an email out to my remote guru and searched for clues in my inbox. That lead me to inspect the files for the compiled version of fabmodules from 2012.

With a bit more insight, I noticed that there was a difference in “flow” values passed between the two versions. In fact, I realized that the default value for flow passed from fabmodules.org conflicted with the profile that I set up for the MDX-20.

Should’ve paid more attention to the help text when I run, “python mod_serial.py”:
command line: mod_serial.py port speed flow file
port = serial port
speed = comm speed
flow = flow control (none | xonxoff | rtscts | dsrdtr )
file = file to send

I was finally able to tame the MDX-20 and fabmodules! And, I was on my way to completing some past assignments.