I fear that your design is not very suitable for PWM dimming. For my own design I decided to go for the MAX6934 which is one of a few remains of the whole driver family and is really great for the job. It has push/pull outputs with slew rate control and a blank input.
Switching the power supply of your drivers with a PWM signal as a workaround for a missing blank signal most likely is a bad idea.
I would try to generate the dimming by using the reset signal of the shift registers. At least this would be worth a try. Shift in the data, with the start of the PWM cycle trigger the latch, immediately after do a reset, and with the end of the PWM on time trigger the latch again. But it is clear that so you cannot set full brightness as after the end of PWM on you will need a bit time to shift the data in again.
You could also try to use the OE signal for dimming but need pull-downs then on the outputs. No idea if the level will drop fast enough when the output goes Z.
Another idea would be to replace the 595 by the 594 which cannot tristate the outputs but instead can clear the latch stage. So you could clock the latch with PWM on and reset the latch with PWM off without the need to retransfer the data.
In my case, using the MAX6934 I use the blank for the basic 8bit dimming. I transfer new data every PWM cycle by DMA and update the data synchronized to the PWM. The PWM frequency is about 20kHz so that I can do another 8 level dimming in software for crossfade effects of every single segment. As with the STM32F0 series I can delegate several operations to the DMA it isn't too expensive regarding processor time.
Regarding the noise: Do you have any MLCCs as bypass or buffers in the power supply rails you currently switch which are not schown in your schematics?
And a last thing: If your schematics are correct the switching of the 30V rail cannot work correctly as even if you turn of the MOSFET the body diode will conduct.
Thank you Torsten and Ty for your excellent suggestions.
I clearly need to do some thinking and experimenting to find the best solution.
It's just so frustrating that the original solution, with the original batch of devices, worked well enough that I didn't even see the problem!
Ok, the solution was, in the end, quite simple - and I post it here just in case it's useful to anyone else.
The problem was, indeed, the 32KHz I had chosen for the PWM. Still not exactly sure why - and why it worked OK on one batch of UDN devices but, dropping the frequency to the default 490Hz fixed the ghosting issue. The problem this created was the audible noise - the reason I had selected the 32KHz in the first place.
So I reasoned that the noise was due to the grids vibrating - since the mass of the grids was so much larger than the individual anodes this seemed logical.
So the solution to the noise was to feed the grids from the non-PWM'd 30V and feed the UDN devices driving the anodes from the PWM.
Problem solved, the clock works (and dims) beautifully.
The UDN2981 is an open-emitter device. Have you tried adding a few pull downs to the outputs to make sure there is nothing being induced? I had a problem much like this, but I was multiplexing, and that makes it a LOT harder to keep the output clean. I used Optos to form a high side switch.
The grid works best when it a quite negative with respect to the filament. If you don't have sufficient reverse bias, the grid is a sloppy control. You might not have enough bias there if the Grid is at 0 and the filament is at 1.65V. Note that there's going to be one end of the filament that is pretty much at GND while the other is at 1.65V. Do you notice that the ghosting is at the top or the bottom of the tune (IIRC, the filament runs vertically).
Are you sure that the 595 are being clocked and latched correctly? I have seen a few things like ghosting in my time that have turned out be be inverted latch signals.
I'm not professing to know any answers - just to give you a few things that perhaps you haven't considered.