I'm reasonably sure that I've found out what's causing the problem with V4 and using binary morphs.

V4's ERC setup (i.e. the Morphs++ figure) uses some chained targetGeoms in the MorphForms (e.g. for combined head/neck movements).
Now V4 will save and load with PMDs on, provided you don't set a value on a channel that's part of a chain.

E.g. Morphform HeadNeckBend

valueParm CTRLNeckHeadBend (Body)<br></br>    - targetGeom CTRLNeckHeadBend (Neck)<br></br>        |-> rotateX (neck)<br></br>        -> rotateX (head)<br></br>

Setting the body or neck NeckHeadBend dial or the head bend dial, saving and attempting to reload results in a crash.
Replacing all the inappropriate targetGeoms with valueParms in the CR2 (there are a lot of them) stops the crashes.

The lesson to be learned from this (as I see it) is to only use targetGeom channels for morphs, any ERC intermediates should be valueParm channels.
It may be that you can use targetGeom channels in an ERC chain, if they have the correct number of morph deltas (rather than 0) for the actor their in, but I haven't checked this yet.

Any observations are welcome.

I've seen this alot (using targetGeom when valueParm should be preferred).  I think some people think that they are interchangeable (?).  But of course, as you note, targetGeom is for morph channels and valueParm is for master dials.  Now, any dial can be a master dial, but it doesn't make sense needlessly to use any old dial when valueParm is the correct option.

I also note that Apollo Maximus uses translateX dials as masters in the ADS support.  Wondering if that would be detrimental similarly (?).

Great observation!

Quote - I also note that Apollo Maximus uses translateX dials as masters in the ADS support.  Wondering if that would be detrimental similarly (?)

I don't think so (we'd have heard something by now if there was).
The difference between targetGeoms in clear text and targetGeoms with PMDs, appears to be that when using PMDs there must be morph data or the dial must remain at 0 (obviously not much use for ERC).
My guess is that there is short circuit logic involved so that when at 0, as deltas wouldn't have any affect, they don't need to be present and correct, move the dial from 0 with no deltas and then bang, no more Poser (could definitely do with being made a little more tolerant in this respect).

Quote - Great observation!

This was beginning to annoy as I couldn't get to crash when I tried it before, but one the the threads at DAZ where I had to tell someone to turn off PMDs made me realised that I hadn't been applying a pose.
I'd suspected it was either the magnets, the special body part, or a return of the problem with same name morphs in more than one figure (or a combination thereof).

Fortunately most items won't be rigged as complicatedly as a (human) figure, the exception being some vehicles (which I'll look at another day, but I expect they'll be Ok).

A bit of useless trivia. I'm new to P6, having just installed it yesterday, so forgive me if what follows is a load of rubish. Further more I don't have V4, so I'm thinking about this issue in a general sense, rather that its original context of the Morphs++ figure (whatever that is). From the experiments I've done, it seems that you can use cascaded targetGeom in conjunction with PMD, so long as all the channels contain deltas. In respect to the crashing problem when a fgure with cascaded targetGeom with no deltas is resaved to a pallet, it seems that it can be overcome by using a zero delta in the intermediate targetGeom channels, eg:

           targetGeom Morph-001
                        {
                        name Morph-001
                        initValue 0
                        hidden 0
                        forceLimits 4
                        min -100000
                        max 100000
                        trackingScale 0.02
                        keys
                                {
                                static  0
                                k  0  1
                                }
                        interpStyleLocked 0
                        valueOpDeltaAdd
                                Figure 1
                                Cube1:1
                                Morph-001
                        deltaAddDelta 1.000000
                         
                        }

This might be much more than useless trivia if such a zero delta channel could be loaded via PMD as a new channel. unfortunately it can't, and this is useless trivia, as under the circumstances using valueParm is a better solution.

Quote - This might be much more than useless trivia if such a zero delta channel could be loaded via PMD as a new channel. unfortunately it can't, and this is useless trivia, as under the circumstances using valueParm is a better solution.

Actually it is a useful bit of info, as I was thinking that a simple fix might be to just correct the number of deltas (seemed likely to be more amenable to scripting).
It looks that you need to do that and add at least one dummy delta.

(Note to self, time to poke at the PMD format)

Progress is being made. @nruddock, I must say that my intrest in this is finding a way to inject new cascaded channels into a cr2. This may be a bit off topic re your thread. If so, my apologies. I seem to have discovered how to save a morph delta that does nothing, and load it via a PMD. What I've done is use a fictitious vertex "d -1", I can now use a positive number for the displacement of the vertex "d -1 0.001 0 0". The real number for the displacement seems to make Poser feel happy about saving/loading the channel to/from the PMD, and the fictitious vertix number stops it from having any effect. I'm assuming that "d -1" is always fictitious.

                   indexes 1
                        numbDeltas 486
                        deltas 
                                { 
                                d -1 0.001 0 0 
                                }

Quote - (Note to self, time to poke at the PMD format)

If you need full info on the PMD format, I'm ya man. :)

*"I've seen this alot (using targetGeom when valueParm should be preferred)."

*I started using targetGeoms instead of valueParms about a year and a half ago, to be able to save the ERC settings in a library pose.  I think that's why Apollo uses the translateX, too.

Bit of a bummer that it causes problems.  :(

Does Poser not include the valueParms when saving a library pose?  If not, how shameful (considering the vast use of them).

I still use Poser 5, which does not save valueParms in a pose file, no.  I can't speak for Poser 6 or 7, however.  Perhaps they have updated the process....