Error 129

[paul_cardinale]

Well this is unpleasant:

If you have things organized in a nice hierarchy, and you use meaningful names, LabVIEW will try to create oversized file names for channel writers.

[billko]

Ugh.  I don't know if there is an equivalent for organizing channels, but my project hierarchies are pretty flat, with most of the organizing done in virtual folders.  I had to do this because some of the folder structures were pretty deep.

[Bob_Schor]

I've been using Channel Wires (mainly Messenger, Tag, Stream, and Event Messenger) since their introduction, often by the dozen per Project, and the path length to the Channel code (in LabVIEW Data) was around 120 characters (as in C:\Users\RSchor\Documents\LabVIEW Data\2019(32-bit)\ExtraVILib\ChannelInstances\Messenger-t'TYPE H-B Msg.ctl'\Instantiate.vi).  Note that the first part of the path is to your Documents folder, and is saved not in your Project (which might have several folder levels to go) but in the default LabVIEW Data folder that LabVIEW puts at the top level of your Documents folder.

For myself, I don't save my LabVIEW code in LabVIEW Data, but in a separate LabVIEW folder, which may have several levels of sub-folders inside to help me keep my projects (I was going to say "organized", but probably "not maximally dis-organized" is more accurate).

Do you believe the Error Message?  Are your supporting Channel Wire files really buried at a location >200 characters long?  [Hmm -- maybe you need shorter Channel Wire names …].

Bob Schor

[paul_cardinale]

---

@Bob_Schor wrote:

...

Do you believe the Error Message?  Are your supporting Channel Wire files really buried at a location >200 characters long?  [Hmm -- maybe you need shorter Channel Wire names …].

Bob Schor

---

 Yes, I believe it.  My project paths are like: X:\Perforce\Source\LabVIEW\<project_name>\ ...

My channel instances are at C:\Users\BDTest\Documents\LabVIEW Data\2018(32-bit)\ExtraVILib\ChannelInstances\

And the data I was trying to send was a cluster of 3 typedef'd items (with all the typdefs being in libraries).

But I had to abandon channel wires in this instance anyway because I wanted to do something like this:

But that kind of forking isn't allowed.  I ended up doing something completely different.

[Bob_Schor]

I was planning to start this by saying "If you weren't supposed to fork it, it wouldn't be an Event Messenger", but that turns out to be the wrong Message about Event Messenger Channel Wires.  I'd actually never tried to do this before your recent reply, but Here's How to Do It -- you create an Event Messenger Channel Wire and use the Read Multiple Event Registration.  Here's an example:  The two Event Loops are on top, with the first one processing the Stop Button that uses a Messenger Channel to tell the Message Handler Loop to stop all the Loops.  The Message Handler stops itself and sends an Event Registration Message to the Read Multiple Event Registration that produces an Array of 2 Event Registration wires, one for each Event Loop.  Event Loop 1 has a 1 second delay (not shown on the Snippet view) and Event Loop 2 has a two-second delay.  Works as you would hope.

Bob Schor