Turning on a HP 41 with the HP IL module plugged

[aurelio]

It's normal a delay turning on the calculator with a HP IL module plugged in? I mean that the display sometimes takes a few second before to show the content of the X register.

[Didier Lachieze]

This is normal if the HP-IL loop is open, or if you have a device turned off in the loop.

You can check if the module works correctly by simply connecting together the two cables from the HP 82160A module. In this configuration the 41C should power on without any delay.

[Sylvain Cote]

Normal delay when the loop is broken or when a device on the loop is powered off.
If you have no device connected, connect the two cable end together so the loop is closed.

Edit: Didier beat me to it.

[aurelio]

Thank-you, both you were so fast in answering, and I so poor in details.....
before to post my situation I've performed a few tests checking if the behaviour depends on the loop, opened (broken), closed, with and without the third hardware (PILBOX) inserted. I took away the HP 82160A module plugging it into another machine, with the same delay (open circuit), then back again in the first calculator, always turn on delayed, then at the third attempt the situation is restored..

[Sylvain Cote]

Check that the module contacts are clean and that they do connect correctly with the flex.
You may have a defective cable, a way to test this is to enter the following program and run it with a close loop.
Play with the cable to see if the tone stop or the beep interval becomes very long, if it is the case then you may have a semi-broken cable.

Code:

LBL "TSTIL"
LBL 01
AVIEW
TONE 0
GTO 01
END

[aurelio]

(05-17-2020 07:19 PM)Sylvain Cote Wrote:  Normal delay when the loop is broken or when a device on the loop is powered off.
If you have no device connected, connect the two cable end together so the loop is closed.

Edit: Didier beat me to it.

Now I have the controller (HP41) + HPIL module + PILBOX connected to a PC, no emulators, and the calculator turns on regularly, it means that just the phisical loop must be closed ?

I got, last time, the problem leaving the calculator connected to the PC after a session of the PYIlPER, and turning it on

[aurelio]

(05-17-2020 08:04 PM)Sylvain Cote Wrote:  Check that the module contacts are clean and that they do connect correctly with the flex.
You may have a defective cable, a way to test this is to enter the following program and run it with a close loop.
Play with the cable to see if the tone stop or the beep interval becomes very long, if it is the case then you may have a semi-broken cable.

Code:

LBL "TSTIL"
LBL 01
AVIEW
TONE 0
GTO 01
END

for "close loop" you mean shortening the connectors of the module?

[aurelio]

(05-17-2020 08:04 PM)Sylvain Cote Wrote:  Check that the module contacts are clean and that they do connect correctly with the flex.
You may have a defective cable, a way to test this is to enter the following program and run it with a close loop.
Play with the cable to see if the tone stop or the beep interval becomes very long, if it is the case then you may have a semi-broken cable.

Code:

LBL "TSTIL"
LBL 01
AVIEW
TONE 0
GTO 01
END

Thank-you, Sylvain, performed the test, it seems the cable is OK on the module, I checked the second cable making the loop on the connector of the PILBOX with the same positiveresult .

[J-F Garnier]

(05-17-2020 08:14 PM)aurelio Wrote:  

(05-17-2020 07:19 PM)Sylvain Cote Wrote:  Normal delay when the loop is broken or when a device on the loop is powered off.
If you have no device connected, connect the two cable end together so the loop is closed.

Edit: Didier beat me to it.

Now I have the controller (HP41) + HPIL module + PILBOX connected to a PC, no emulators, and the calculator turns on regularly, it means that just the phisical loop must be closed ?

I got, last time, the problem leaving the calculator connected to the PC after a session of the PYIlPER, and turning it on

With the PIL-Box, a "closed loop" has a slightly different meaning.

When the PIL-Box is powered up, it justs re-transmits the HP-IL traffic to the controller (the 41C), so the loop is closed.
But when an application on PC initializes the PIL-Box, the PIL-Box starts to re-transmit the HP-IL traffic to the PC. If the application doesn't reply for some reason, the loop is "broken".

With the regular ILPer, the PIL-Box is put back to simple re-transmission on HP-IL side when the application terminates, so the loop is still "closed" when the application has ended. I don't know for pyILPER.

J-F

[aurelio]

(05-18-2020 08:00 AM)J-F Garnier Wrote:  

(05-17-2020 08:14 PM)aurelio Wrote:  Now I have the controller (HP41) + HPIL module + PILBOX connected to a PC, no emulators, and the calculator turns on regularly, it means that just the phisical loop must be closed ?

I got, last time, the problem leaving the calculator connected to the PC after a session of the PYIlPER, and turning it on

With the PIL-Box, a "closed loop" has a slightly different meaning.

When the PIL-Box is powered up, it justs re-transmits the HP-IL traffic to the controller (the 41C), so the loop is closed.
But when an application on PC initializes the PIL-Box, the PIL-Box starts to re-transmit the HP-IL traffic to the PC. If the application doesn't reply for some reason, the loop is "broken".

With the regular ILPer, the PIL-Box is put back to simple re-transmission on HP-IL side when the application terminates, so the loop is still "closed" when the application has ended. I don't know for pyILPER.

J-F

Thank-you, J-F, It means if I understood that the first test to do (with the Sylvain's program) is the integrity of the whole phisical loop with the PILBOX connected to the PC (this way USB powered), without any emulator, then if there is a failure, I can look eventually for any issue related to the cables, reducing each time the lenght of the loop.
Yesterday I've done this job in areverse way.

When I got last time the problem, it was with the calculator connected to the pilbox, connected to the PC (USB powered), it means that maybe the broken (opened) circuit was in the COM, maybe quiting the PYILPER, the port was left "opened" on the PC