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

My apologies for the delayed response. I haven't been able to dedicate any time to address the issues with the automation of my mill lately. I had a brief period where I was waiting for parts and tooling, which is why I was able to spend those 4 weeks specifically on this issue, but they have all arrived now. I was hoping to have this mill ready to contribute like the rest of my machines when the parts arrived, but we're obviously not there yet and I have to do what I have to do with or without this machine.

In response to who is commenting on this thread -- Good. I'm glad that I have the top tier looking at this. That means that these are the people I WANT to be talking to and that SHOULD be able to diagnose and solve the issues I am having -- above and beyond ANYONE else. I understand that people are simply trying to help and I appreciate that. I've said that multiple times. I am not trying to be condescending or rude in any way. I am a very up-front person and I call things as I see them. I was a CEO for 12 years before I started my own company. I am problem-oriented and results-driven. It's just my personality.

While I admit that I am new to Linux, that doesn't mean that I am a neophyte (as was so kindly suggested), stupid, or incapable of executing simple tasks outlined online or by someone commenting and directing me here in the forum - such as finding my parallel port address and inputting it into my HAL files. I really don't know any other way to say that "I have the port address of e010 entered into the appropriate places in the HAL files - both the machine's HAL file and the port tester HAL file - and it works absolutely fine for manually switching the relay on the BOB on and off as well as sending voltmeter-verified test signals to the pins", other than to say it like I did just now. I've checked, and re-checked, and double re-checked multiple times and have reported back with these same results each time, so it can be reasonably believed that the parallel port address is not the problem, correct? Perhaps my initial titling of this post is a little vague and should have been a little bit more refined in its meaning to say something to the effect of "Linux will not TALK to my BOB", rather than "Linux will not RECOGNIZE my BOB", because I actually CAN send manual signals to the pins through the port tester.

I will attach my HAL and ini files to this post for convenience, though they have been uploaded to this string at least twice already.

Across all of the computers I have tried this system on, they all generate the same error. Everything I can find online references the initialization of the RTAI kernel which, I assume, then allows the parport_pc driver kernel to control communication to/with the parallel port? That is not happening on any of my systems.

sudo cat /proc/ioports shows no kernel driver in use for the parallel port that Linux has the correct address for and can clearly see.

As for saying that it all worked until it didn't, it all worked the first time I installed Linux, plugged in all of the hardware, and went through the StepConf Wizard. I had full manual control of the machine and was able to open and run the Axis GUI with no problems. The computer crashed and I have lost all control of everything since. Like I have said -- It all worked until it didn't. I can't be any more succinct than that.

I would LIKE to use Linux on this machine -- as well as a couple more that I have ready to convert -- which is why I am STILL spending my personal time trying to figure this out. I do believe that is the leading software and I do believe it will work the best for what I am trying to do, but if I can't get it to work, then I can't use it. Period. It is a simple equation. I have the same problem across all of the systems this is installed on. If a solution can be found for one, I believe it will work for all.

Thank you for your response and suggestion, Andy. I hope you had a great Memorial Day Weekend and took a few moments to reflect on those that have given the ultimate sacrifice to allow us to have the freedoms that we enjoy, and that are so rapidly being eroded away. Ok. Enough politics.
I have changed the .steplen and .stepspace values from 1 to 5000 like you suggested and then tried to start the Axis GUI. I got the white ERROR/DEBUG screen and have attached the error output file. I noticed that in the DEBUG section, it again appears (to me) to be saying that the problem is with the parport_pc module. When I open a command terminal and type insmod parport_pc, nothing changes in Linux's ability to load the parport_pc module. Your next thought??

Andy is in the UK. I think they do their memorial day on a different date.

parport_pc is the standard parport driver for printing from Linux. It is NOT a real time module, and should not be used in LinuxCNC. The correct module is hal_parport.
I don't know what you have done to your config to cause LinuxCNC to try to load parport_pc, but that is the wrong module. Ahh, I see you have :

loadrt parport_pc

That is your error, it CANNOT work like that, parport_pc has all the wrong software interface for what LinuxCNC wants it to do. Where did this mill.hal file come from?

You should have :

loadrt hal_parport cfg="0xnnnn" where nnnn is the parport address. I see you DO have this, so just REMOVE
loadrt parport_pc


Jon

Oops.... Well, Happy Memorial Day Andy (whenever yours is) because the meaning is the same for everyone -- honor the troops and remember the sacrifice of fallen in our behalf.

To be perfectly honest with you John, with the exception of changing the parallel port address from 0 to e010 and making the changes that Andy just suggested to the step length and step space, those files are exactly as they were generated by the StepConf Wizard. I have not changed anything in them. I opened the StepConf Wizard and followed the prompts, and those were the files that it created.

I have removed the "loadrt parport_pc" from the HAL file and tried to open the Axis GUI. It allows me to open the GUI, but it is still giving me the "Linux parallel port @57360 not found" error in the bottom right of the display screen.

what are you referencing, exactly? Andy's .steplen and .stepspace values, or John's loadrt parport_pc comment?

I ask because those commands only appear in the HAL files that were created by the StepConf Wizard. If they are supposed to be in the .ini file, 1) why wouldn't they have been put there to begin with, and 2) where am I supposed to put them in the .ini file if they are not there already?

Kidkasual1 wrote:

I have removed the "loadrt parport_pc" from the HAL file and tried to open the Axis GUI. It allows me to open the GUI, but it is still giving me the "Linux parallel port @57360 not found" error in the bottom right of the display screen.

This error is spurious. I hope somebody takes it out, or reworks the code so it doesn't come out for no reason.

The actual issue is that LinuxCNC needs to take control over a parport that WAS assigned to the OS, to avoid a conflict.
If the port requested in the hal file is NOT in use by the system, then you get this message. And, the message really doesn't mean what it says!

What it should say is something like "I asked Linux to give me exclusive control over the requested parallal port, but since Linux did NOT have control of the port, it would not give me control." Since NOBODY has control of the port, it is perfectly safe for LinuxCNC to just take control.

Jon