[Problem solved] Upgrade to 2.8: parport X-mode problem

More
05 Nov 2019 14:24 - 06 Nov 2019 11:05 #149602 by Elco
After a LinuxCNC upgrade (2.7->2.8) I reinstalled my CNC configuration, which is build to run the parport in X-mode. The configuration ran correctly in 2.7.

On the same hardware, 2.8 recognizes the parport X-mode, but creates an error. Referring to table 11.1 in the manual, all ports specified as 'In' (1, 10, 11, 12, 13, 14, 15, 16, 17) have direction OUT, and all 'out' ports have direction IN.

.hal file attached.

File Attachment:

File Name: cnc_3.hal
File Size:4 KB
Attachments:
Last edit: 06 Nov 2019 11:05 by Elco. Reason: Problem solved

Please Log in or Create an account to join the conversation.

More
05 Nov 2019 15:38 #149610 by pl7i92
did you change the OS also
or only the linuxcnc version
the Master is not very clear on the X-mode as it has only base parport functions due to interpreter reriting
i guess there can be somthing with the X-mode
Why at all arent you using not only the out in mode
and select a second parport for Servo tread usage

Please Log in or Create an account to join the conversation.

More
05 Nov 2019 15:53 - 05 Nov 2019 15:58 #149614 by Todd Zuercher

After a LinuxCNC upgrade (2.7->2.8) I reinstalled my CNC configuration, which is build to run the parport in X-mode. The configuration ran correctly in 2.7.

On the same hardware, 2.8 recognizes the parport X-mode, but creates an error. Referring to table 11.1 in the manual, all ports specified as 'In' (1, 10, 11, 12, 13, 14, 15, 16, 17) have direction OUT, and all 'out' ports have direction IN.

.hal file attached.

File Attachment:

File Name: cnc_3.hal
File Size:4 KB


Is your configuration not opening? Are you getting an error message(s)? What is it?

As to the inputs pins having the hal pin direction as out and the output pins the direction as in, it is normal. It is a slightly confusing side of most hal hardware drivers. A parallel port input pin, receives a signal from an outside source, such as a limit switch, but in hal that signal from parallel port input is actually seen as an output, because the parallel port driver is outputting the signal it received to hal.

I am running several machines using parallel port X-mode, but none of them are running 2.8 or Master. But I have not noticed any problems with X-mode in simulations that I have ran on Master (but I have not tested on real hardware.)
Last edit: 05 Nov 2019 15:58 by Todd Zuercher.

Please Log in or Create an account to join the conversation.

More
05 Nov 2019 16:11 #149616 by Elco
This is Linux 2.8 on Linux Mint 19.2. I did not see errors on that installation, and the simulation examples worked normally. The configuration is correctly opening and I got the direction from the Hal monitor, that specified parport.0.pin-01 for instance as OUT.

As I replaced my 2.7 system, I cannot directly compare, and I might be wrong here. However I could not trigger Estop with a signal on that pin. Will try again.

Thanks.

Please Log in or Create an account to join the conversation.

More
05 Nov 2019 16:18 #149617 by Todd Zuercher
Yes, if you had checked HalShow in 2.7 you would have seen the same thing.

Please Log in or Create an account to join the conversation.

More
05 Nov 2019 16:25 #149619 by pl7i92
check your connection it seams a loosen cable if all starts up

Please Log in or Create an account to join the conversation.

More
06 Nov 2019 11:04 #149689 by Elco
Thanks for advice.
The problem was solved by changing the parallel port BIOS setting from 'Bidirectional mode' (which did not work) to 'EPP'
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
06 Nov 2019 13:22 #149710 by Todd Zuercher
Really??? My experience with X-mode and Bios settings have been the opposite. But it wouldn't be the first time a computer manufacturer screwed up something like that.

Please Log in or Create an account to join the conversation.

Time to create page: 0.090 seconds
Powered by Kunena Forum