LPub3D 2.0 Released

[Merlijn Wissink]

Merlijn - take a look at this post on a good pattern for using the BUFEXCHG meta in LPub3D. 

Let me know if after you adjust your BUFEXCHG procedure accordingly, the unexpected behaviour continue ?

The post presents a detail use case with supporting LPub3D and LPub assets comparing and explaining how the BUFEXCHG meta should be used. I believe an anomaly in the way LPub managed its cache files, and the difference in the way MLCAD treats the meta, have led to incorrect expectations about the way the meta can be used with LPub3D.

Cheers,

Well, as in the post you linked, I expect 'V1 correct behavior' but I'm seeing 'V1 incorrect behavior'. I'm 1000% sure that an old version of LPub had the 'correct' behavior, as shown by Johann.

But of course it depends on what you think is correct. Now that I think of it, I think it's better to call the 'incorrect' version on your link the 'correct' version (because technically, it's doing exactly what the file says) and to call the 'correct' version the 'desired' version. Because, 99% of the time you use buffer exchange, you want a floating part with arrows in step 1 and the part in its final position in step 2 without adding it to the PLI again.

As the post described, a way of doing it currently is by adding ignore commands to all final-position parts. But, in a large model, that'll start to clutter up a lot of things and it's very inconvenient. Maybe, just maybe, we need to introduce a new command? After all, buffer-exchange is an (ancient) MLCad-command and LPub just added support for that. There's no reason LPub3D can't introduce its own command (there are so many already after all).

I'm just thinking out loud here, but maybe something like this (based on MLCad's version, it doesn't have to be completely different):

Code:

[other parts in the step]
0 !LPUB BUFFER A STORE BEGIN
[parts and arrows to store here]
0 !LPUB BUFFER A STORE END
[other parts in the step]

0 STEP

[other parts in the step]
0 !LPUB BUFFER A RETRIEVE BEGIN
[final position parts]
0 !LPUB BUFFER A RETRIEVE END
[other parts in the step]

It's not too different from the MLCad version, but it does solve a lot of headaches. Because it has a clear begin and end for both the store and retrieve commands, it would be fairly easy for LPub3D to automatically make correct assemblies and PLIs. And, it also makes adding it way less of a headache, current buffer exchange is position-dependent, which is incredibly annoying if you forget to move a line up or down 
Now, of course, you could also take it a step further and make a more complicated buffer exchange with more features. Cross-submodel buffer store/retrieve for example (in other words, e.g. buffer A is not only known in the submodel it's in, but is known model-wide), but I have no idea if that would be easy to use at all.