Linux will not recognize my BOB no matter WHAT I try to do

The error message is spurious, it is because you are not using a port that has been taken by Linux, and askingn Linux to GIVE you control of that port.

If you can control the pins going to the step input of the drive, you should be able to move it in TINY increments by toggling the step output pin high and low. If not, then maybe the common connection to the drive needs to be checked. It probably takes either +5 or ground to the other side of the opto inputs. Also, those drives have 2 direction inhibit inputs that can be connected to limit switches to stop the axis when it hits the limit switch. Make sure those inputs are in whatever state is required to permit motion. If it is accepting the step commands, you should at least hear the motors click on every rising (or possibly falling) transition of the step signal.

Make sure the output pins assigned to step are connected to the step input of the drive, and the direction pins are connected to the direction input.

As for that error message, you are apparently requesting a 53 us base thread. While this is not insanely fast, it may be too fast for your specific computer, as the kernel has been set up. There may be boot time options that will make it run better. But, for now, just back off on the bast thread, which means increasing the period number.
This is set in the .hal file.

Oh, but that is ONLY for the ptest.hal program, not LinuxCNC. But, you can edit the file to fix that error.


Jon

jmelson wrote: Yes and no. parport_pc is a real time module, so it looks like a kernel module, but requires services from the real time system, so it can't be run as a normal kernel device driver.

I think that perhaps you are conflating parport_pc and hal_parport?

I think that the absence of parport_pc is the reason for the "Linux parallel port not found" (Note the "Linux" part of the message). ie when loading hal_parport the system is not finding a port that has been found by parport_pc.

The message is spurious, confusing, and we probably should have another go at getting rid of it.

Kidkasual1 wrote: I noticed this line in the terminal after I ran that last parallel port test in which I FINALLY got signals at the pins. Could this possibly be the cause of all of the trouble? If the system can't or isn't creating a base period to run everything from, would that cause the problems I am having??? And if so, how do I fix that?

Yes, this could, indeed, be the problem.

The most likely cause is that the parport tester failed to quit cleanly and has left some modules loaded.

Try "halrun -U" to see if that clears things up. If not then you might need a reboot to untangle the mutually-dependent kernel modules.

andypugh wrote:

jmelson wrote: Yes and no. parport_pc is a real time module, so it looks like a kernel module, but requires services from the real time system, so it can't be run as a normal kernel device driver.

I think that perhaps you are conflating parport_pc and hal_parport?

Whoops, I was thinking right, but wrote it wrong! I MEANT hal_parport!

Thanks for the correction,

Jon

Good morning, all.

Ok, so I have run a base thread max jitter test using the StepConf wizard to re-establish my baseline number. (See pic 1)

Then I opened and re-ran the port tester to make sure that I was still communicating with the BOB. Yup. All good. +5V(ish) at all of the pins and I can toggle pin 17 (relay) on and off at will. (See pic 2)

Then I opened StepConf wizard and changed the base thread max jitter number to the new number reported by the test, saved, and rebooted.

Then I tried to open the Axis GUI, but this time instead of opening, it threw me the white error screen with a new debug error that I haven't seen yet. (See pic 3).

I believe that we are MOST DEFINATELY getting down to the root of the issue now. Regaining signal generation to the pins was absolutely HUGE. Now if we can fix the base thread real-time mismatch going on, I think we might have this in the bag. THANK YOU, guys!!!

Yeeeaahhh..... I am a doofus... I changed one of the settings in the StepConf to try a few things and forgot to change it back before I started up the Axis GUI. That is what threw me the debug screen. I changed everything back to what it is supposed to be and now I am back to where everything was last night with the Axis GUI opening but not finding the parallel port. Still need to figure out the base thread timing thing and I think we're good.

The button at the bottom of that error dialog will create a text file of the full error report that you can attach to a forum post. This will help us see what it going on.

Start LinuxCNC from the command-line with the command "linuxcnc" then jog an axis, then quit, and paste all the terminal output here.

Perhaps we can spot something.

Ok, so when I type "linuxcnc" into the command line, it doesn't start LinuxCNC. It opens the window in Linux configuration selector referring to the Parport Test using pyvcp. (See pic) If I click "cancel", it just closes the program. If I click "ok", it just opens the generic parport tester GUI that isn't connected to or communicating with my parport (i.e. not address e010).

Yes, it will open the config selector dialog with the last-used one highlighted. You have to go through the list to find the specifc config you want to run. There will be two top directories, one is your user account (My Configurations), the other is the sample configs as supplied with the install. Note that you have to drill down to the end of the tree to find the .ini file, just selecting the directory won't get it to start.

Jon