So I figured it out, the whole thing was working just as advertised, only I had incompletely triangulated the truss frame. So when the script tried to solve the problem, the whole frame collapsed as it still had degrees of freedom to move.
After Christophs suggestion to try simplifying the case to see if I could get it to work, I created a smaller truss frame with only two of the five frames, and associated reduced load case. It still failed part way through the solution but printed the undistorted truss anyway:
If you look at this frame, you will see that the node at 0,0,~300 is not constrained in the x-direction. Hence when we try to solve for this data set, the script returns a 'NaN' answer. This is because that node weeble-wobbles off into the distance as the whole frame collapses.
I added one extra frame member between the uncompletely restrained node and the node nearest to it in the x-direction. When we solve for the frame with the extra member included we see:
The undeformed truss and the deformed truss!
Now back to the original 4-bay frame with 4 off added members tying together the five affected nodes and the original loading case restored we see:
The complete frame in both distorted and undistorted shapes (note the 4 off extra members across the middle of the lower level of the frame compared to the picture in my original post).
So thank you to Christoph for your suggestion to try simplifying things to see if that showed the problem. Your prompt caused me to notice where the mistake in my frame was.
To solve for my original frame I probably need to learn how to use one of the other scripts in Larrys Toolbox, 'frame3.m'. This script has internal moments in the mebers, and hence could deal with a stiff joint in the noted locations and thus would not need the extra members.