Altium Unable to cast COM object type

Summary

This blog describes how Altium users can resolve the "Unable to cast COM object type" which can be caused as a result of installing / uninstalling Office (32 bit) software together with Office (64 bit).

Altium Dialog Message

The "Unable to cast COM object type" message can be displayed when there is a requirement for Altium to use Excel libraries, such as generating a Bill of Materials (BOM).

Altium Dialog Message

The message identifies a registry entry which is located at HKCR\TypeLib.

Causes

One Microsoft blog explains that the message may be displayed within Office applications when a mixture of Office 32/64 bit applications are installed on the same machine. The Microsoft blog suggests removing the HKCR key 

00020813-0000-0000-C000-000000000046 although applying this change with Altium did not resolve the issue.

Registry 00020813-0000-0000-C000-000000000046 Entry

Office Repair

To remedy the issue in Altium, an Office Repair was required. With the Altium application closed, may not be necessary, the Apps and Features application was opened from the 'Start' menu and the relevant Office installation selected.

Windows 10 Apps and Features

The Modify button was selected followed by the Quick Repair.

Office Quick Repair

Quick Repair Started

In a few minutes the repair finished.

Quick Repair Finished

After the repair Altium was launched and a BOM generated without any issues.

Other Altium Messages

While replicating the "Unable to cast COM object type" Altium message for this blog, the process of installing 32 bit Office software did interfere with another Microsoft redistributable. This resulted in Altium displaying a dialog detailing the missing redistributable. Fortunately the Altium dialog provided a link to the Microsoft website where an installation of the redistributable resolved the issue.

iC-Haus SSI Data Parity Check

Summary

This blog provides one solution for calculating the parity of a data stream which has been obtained using an SSI interface from an iC-Haus magnetic encoder.

Reason for SSI
Magnetic encoders from iC-Haus perform well for position sensing and are ideally suited for battery backup installations because of their low current consumption. One constraint with these encoders is that the data output of the SPI and SSI communications interfaces is different. It should be pointed out that the hardware solution required with the encoder will largely dictate the communications interface used in the design.

iC-Haus Communication Modes

From the communications interface, information such as the angle offset 'synchronization bits' is available using the SSI but not the SPI communication. The angle offset can be useful if the offset needs to be manually changed or set to a specific setting depending on external conditions.

iC-Haus Angle Offset

While obtaining SSI data from the encoder, data integrity can be achieved using an optional parity bit.

iC-Haus Parity Options

The parity bit is located at the end of the SSI data packet. It should be noted that the MT - Multiturn bit width shown at the beginning of the packet below, is user programmable between 9 and 40 bits.

iC-Haus SSI Data

SSI Data Parity Check
For a SSI data payload of 32 bits, calculating the parity could be achieved using a number of methods. One option for performing this calculation, which may not come to mind immediately, is calculating the parity in five steps. 

Such an example is shown in the code below. Courtesy of Sean Eron Anderson at Stanford University and the associated Bit Twiddling Hacks page for the implementation below.

unsigned int v;  // word value to compute the parity of
v ^= v >> 16;
v ^= v >> 8;
v ^= v >> 4;
v &= 0xf;
return (0x6996 >> v) & 1;

There is a lengthy explanation of the 32 bit parity check and an explanation of a 64 bit implementation by Hraban on his blog http://br0g.0brg.net, credit for helping wrap my head around the 0x6996!

Rigol DP832 with standard banana plugs

Summary

This is more an 'instructables' rather than a blog post and relates to the undersized banana post holes on older model DP832 power supplies.

Rigol DP832

Undersized Binding Post - Early Models

Although I had been using the Rigol DP832 for some time, there only recently became a requirement to upgrade the leads used with the power supply. There has been an issue with the early model DP832 binding posts which had been mentioned on a number of forums such as the EEVBlog.

It should be noted that the newer DP832 models (second half 2017 builds and possibly earlier) have the larger 4mm sized internal hole in the binding posts.

Binding Post Drilling
Armed with a 4mm drill bit in the drill, the first binding post was carefully brought into a state of banana compatibility.

DP832 drilling binding posts

After the first binding post was drilled and the metal shavings removed, a new banana plug was tested - snug fit! Disclaimer - Modify the binding posts at your own risk. This posts shows how the binding posts were modified on my Rigol DP832.

DP832 new banana plug test

Using the 4mm bit results in a fit for the banana plug which is tight and my preference when handling anything power related. A 4.1mm bit was not tried however this was mentioned in the EEVBlog forum.

DP832 with newly drilled binding posts

The depth to drill the binding post is somewhat dependent on the original hole depth. 

DP832 binding post hole depth

On average the depth of the hole in the DP832 binding posts that were drilled was between 16-18mm. It should be noted the exposed metal section of a standard banana plug is approximately 18mm, however contact with the banana plug is achieved in the first 12mm of the banana plug only.