HP-71B Auto on

[Erwin]

Dear community,

I registerd an Auto-On on my HP71B. No idea what is the source for this. There is no Clock LEX installed or Alarm function. But it sucks my battery to death.
Does anyone have an idea where I can look at this problem?

best regards
Erwin

[J-F Garnier]

What do you mean exactly with "Auto-On"?

Does it stay on with no automatic switch-off after 10 minutes? If yes, it may come from flag -3.
Or does it periodically turn on, every minute, every hour, ... ?
or does it immediately turn on again when switched off?

J-F

[Erwin]

Hello,

Thanks it was Flag-3 … I don‘t think on this. Problem solved … „beginners fault“

Best regards
Erwin

[Erwin]

Good Morning,

sorry problem not solved finally. Now I noticed that my HP71 switches on after a certain time. I noticed that this is exact after 5 hours after switched off.
So I have no idea where this comes from.
In the meanwhile I put it on the mains cause this problem sucks my batteries off.

Do anyone have an idea how to solve this?

best regards
Erwin

[J-F Garnier]

Indeed, the HP-71B CPU wakes from deep sleep every 4.55 hours to update the real-time clock. This is normally transparent to the user.
But if there is an unhandled service request at this point, this may leave the HP-71B awake.

A possible source of unserviced requests is the HP-IL.
You didn't give much details about your confguration, but if you have a HP-IL module, then try RESET HPIL.

A INIT 1 may help too.

J-F

[Edit:]
More details and example of HP-IL unhandled service requests here.

[Sylvain Cote]

The behavior you are seeing are happening to me when I am pushing the HP-IL interface to its limits.
Like Jean-François is suggesting, RESET HPIL normally works, but sometime it does not, when that happens I do a hardware reset like the following ...

• HP-71B OFF
• remove HP-IL module
• HP-71B ON
• wait a couple of seconds
• HP-71B OFF
• insert HP-IL module
• HP-71B ON
• RESET HPIL
  

[Erwin]

@Sylvain @J-F
thanks a lot. Maybe it is from my programming the FRAMB new and the HPIL is broken - cause I did no disconnect properly.
So I tried the first step ... RESTORE IO --> Result: HPIL Look broken. So I connected the loop and did the same with positive result, Afterwards I did the RESET IO.
So I let it in this state and look at it after tomorrow. If this fails I'll try the. next proposals.
Thanks for learning me some secrets :-)

In the next weeks I put some of my equipment together (second HP71B, and some modules, some HPIL devices I have in double etc) cause I have the FRAMB and I'm very satisfied with it.
Will the doubled parts leave to people who are happy with it. I only keep the core elements, cause I use the HP71B and some peripherals (printer, disc serial HPIL)

So thanks a lot for your hints - I will give feedback about the results

best regards from Vienna, Austria
Erwin

[J-F Garnier]

(02-07-2023 04:30 PM)Sylvain Cote Wrote:  The behavior you are seeing are happening to me when I am pushing the HP-IL interface to its limits.

Athough the problem of a HP-71B refusing to turn-off is easily reproducable (see my old post), I don't know any sequence/condition that causes a HP-71B to wakeup after 4.5 h and stay on. I would be interested to know how it can be reproduced.

J-F

[Erwin]

Maybe it’s from my configuration of the FRAMB and not close the connection to the PIL-Box in a clean way. I didn’t do any other tasks with the HPIL connection. Before installing on the FRAMB I cleared the Modul from ground up - so nothing should be left on the system
Best regards
Erwin

[Erwin]

Good Morning ... problem solved - thanks for your investigation on this problem. So my batteries are happy again.

kind regards
Erwin

[Sylvain Cote]

(02-07-2023 07:30 PM)J-F Garnier Wrote:  

(02-07-2023 04:30 PM)Sylvain Cote Wrote:  The behavior you are seeing are happening to me when I am pushing the HP-IL interface to its limits.

Although the problem of a HP-71B refusing to turn-off is easily reproducible (see my old post),
I don't know any sequence/condition that causes a HP-71B to wakeup after 4.5 h and stay on.
I would be interested to know how it can be reproduced.

Last year I did a lot of HP-IL testing while I was writing my HHC/Allschwil presentation on HP-IL asynchronous communication.

My main test setup was:

• 6 x HP-71B (1BBBB) with HP-IL module (1B)
• 2 x PIL-Box
• 1 x pyILPER (with virtual scope and virtual display)
• 1 x pyILPER (with virtual scope and virtual tape).
  

One of the tests involved saturating the HP-IL loop with asynchronous messages between all the 71Bs for an extended period of time. (~120 hours)

This specific test revealed two faulty HP-IL interfaces.
These interfaces were working correctly with light traffic but they failed under serious stress.
The symptom was that at some point the 71Bs who had the faulty interfaces were experiencing a memory lost after several hours in the tests.
Swapping interfaces between machines revealed that the issue was following the HP-IL interfaces and not the 71B computers.
Once those interfaces were removed, the communication worked for the duration of the test.

Like you mentioned in your old post, manually interrupting a 71B with the ATTN key with pending interrupts sometime cause the 71B to stay on.
If I remember correctly, it also happened when a faulty interface was resetting its 71B on the loop,
creating a broken loop message for the other 71Bs present that sometimes stopped the program while processing an IRQ.
When that happened, RESET HPIL normally worked but in some cases I had to do a hard reset to put back the 71B on its feet. (hard reset → off;unplug;on;wait;off;plug;on;reset)

Sylvain

[J-F Garnier]

(02-09-2023 03:49 PM)Sylvain Cote Wrote:  My main test setup was:

• 6 x HP-71B (1BBBB) with HP-IL module (1B)
• 2 x PIL-Box
• 1 x pyILPER (with virtual scope and virtual display)
• 1 x pyILPER (with virtual scope and virtual tape).
  

One of the tests involved saturating the HP-IL loop with asynchronous messages between all the 71Bs for an extended period of time. (~120 hours)

This specific test revealed two faulty HP-IL interfaces.
These interfaces were working correctly with light traffic but they failed under serious stress.
The symptom was that at some point the 71Bs who had the faulty interfaces were experiencing a memory lost after several hours in the tests.
Swapping interfaces between machines revealed that the issue was following the HP-IL interfaces and not the 71B computers.
Once those interfaces were removed, the communication worked for the duration of the test.

This is particularly interesting. So it seems there are some hardware variations of the HP-IL module 1B.
I already suspected it for the module 1A, because some (not all) of them have problems with the PIL-Box, and I was able to identify timing variations, that don't harm with the genuine HP-IL devices but do with the PIL-Box.

J-F

[brouhaha]

(02-10-2023 08:11 AM)J-F Garnier Wrote:  So it seems there are some hardware variations of the HP-IL module 1B.

There's a microcontroller in the -71 HP-IL module, which provides the mailbox interface to the Saturn bus. The microcontroller has firmware in masked ROM. It's possible that it was revised, without requiring a change to the 1B Saturn ROM. There's probably a way to interrogate the microcontroller ROM version through the mailbox.

There seems to be nothing published about the microcontroller other than its existence. I think it might be related to the microcontroller in the Thinkjet chip, but that's just a wild guess, as there's no public information on that either.

[Erwin]

(02-09-2023 03:49 PM)Sylvain Cote Wrote:  Last year I did a lot of HP-IL testing while I was writing my HHC/Allschwil presentation on HP-IL asynchronous communication. […]

One of the tests involved saturating the HP-IL loop with asynchronous messages between all the 71Bs for an extended period of time. (~120 hours)
[…]

Ä
Sylvain

That‘s a true stress test :-) how did you perform it? So we can investigate the HPIL modules … :-)

Regards Erwin

[Sylvain Cote]

(02-10-2023 12:34 PM)Erwin Wrote:  That‘s a true stress test :-) how did you perform it? So we can investigate the HPIL modules … :-)

You need at least two HP-IL connected HP-71B, with one acting as a controller and the other(s) acting as device.

On the controller machine load the BC5C program (P.46) and on the device machine(s) load the BC3D program (P.45).
These programs were part of my Advanced HP-IL Communication presentation given at HHC 2022 and at Allschwil 2022 meetings.

Advanced HP-IL Communication Allschwil Presentation

• Presentation (YouTube)
• Document (.pdf)
• Archive (.zip) → demos (.mov) & virtual tape (.dat)
  

The BC3D program assumes multiple devices and adds a delay line to show the asynchronicity of the communication.
If you want the maximum throughput, comment line 40.

Code:

...
40 ! SFLAG 1 @ WAIT IP(RND*10+1)/10 @ CFLAG 1
...

Sylvain

[J-F Garnier]

(02-10-2023 09:03 AM)brouhaha Wrote:  

(02-10-2023 08:11 AM)J-F Garnier Wrote:  So it seems there are some hardware variations of the HP-IL module 1B.

There's a microcontroller in the -71 HP-IL module, which provides the mailbox interface to the Saturn bus. The microcontroller has firmware in masked ROM. It's possible that it was revised, without requiring a change to the 1B Saturn ROM. There's probably a way to interrogate the microcontroller ROM version through the mailbox.

The microcontroller is described in the HP-IL IDS as a "CMOS chip with cycle time of 1u sec, 272 bytes of RAM and 4096 bytes of ROM". 131 RAM bytes are used for I/O buffers.
There are diagnostic commands to perform a RAM/ROM self test with just a OK/NOK result, and to read/write RAM locations. No way to get a firmware version or read the ROM (or if there is, this is undocumented).

J-F