I'm looking for the simplest and/or best way to run two do-loops concurrently. I can do this with two separate scripts running in two separate windows...but I'm sure there's a more efficient way. I played a little with the "workspace" method, but haven't yet figured it all out. Is the workspace approach the best way? Is it the easiest way? A sample script that launches two do-until loops concurrently would be appreciated. Here are to two scripts I have running in separate windows now:

SCRIPT 1--

$relayoff = {

do {
$request = get-content relay.txt
} until ($request -notmatch '0')

&$relayon

}

$relayon = {

$port= new-object system.io.ports.serialport com7,4800,none,8,one

$port.open()

echo 1 > relay.txt

do {
$hold = get-content relay.txt
$port.writeline("1InthebeginningwastheWord,andtheWordwaswithGod,andtheWordwasGod.2HewasinthebeginningwithGod.3AllthingsweremadethroughHim,andwithoutHimnothingwasmadethatwasmade.4InHimwaslife,andthelifewasthelightofmen.5Andthelightshinesinthedarkness,andthedarknessdidnotcomprehend[a]it. ")
} until ($hold -match '0')

$port.close()

&$relayoff

}

&$relayoff

SCRIPT 2--

$wait = {

do {
$read = get-content relay.txt
$request = $read
} until ($read -notmatch '0')

do {
$read = get-content relay.txt
} until ($read -match '1')

&$play

}

$play = {

.\sounder.exe $request

Wait-Process sounder

echo 0 > relay.txt

&$wait

}

$read = get-content relay.txt

&$wait

Flags and other information are passed between these two scripts and a GUI via the text file "relay.txt".  So currently there are three programs running concurrently: two powershell windows and the GUI.  If I can combine the two scripts, I will eliminate one of these windows. I'll still need the text file for the sake of the GUI, but not for the do-loop variables.

• Edited by Chalk-X CPG Monday, February 09, 2015 7:13 PM

I'll look at this method.  Is this simpler than the "workspace" approach?
  Can you give me an example with two do-until loops comparing variables and running concurrently?

Okay...looking at the help content.  Looks pretty simple.  Question: If I start two jobs, JOB1 and JOB2...and JOB1 creates a variable, can that variable be read by JOB2?

• Edited by Chalk-X CPG Monday, February 09, 2015 7:50 PM

Okay...So I created a simple test script designed concurrently run a couple of (actually three) do-loops that all read the contents of a text file and echo responses back to the screen:

$job1 = {

$tweedledee = {

do {
$read = get-content C:\Users\Bob\Desktop\test\mediate.txt
} until ($read -match 'hello tweedledee')

echo 'tweedledee is alive' > C:\Users\Bob\Desktop\test\mediate.txt

&$returndee

}

$returndee = {

&$tweedledee

}

&$tweedledee

}

$job3 = {

$tweedledum = {

do {
$read = get-content C:\Users\Bob\Desktop\test\mediate.txt
} until ($read -match 'hello tweedledum')

echo 'tweedledum is alive' > C:\Users\Bob\Desktop\test\mediate.txt

&$returndum

}

$returndum = {

&$tweedledum

}

&$tweedledum

}

$monitor = {

do {
$check2 = $check1
$check1 = get-content mediate.txt
} until ($check1 -notmatch $check2)

&$screenecho

}

$screenecho = {

echo $check1

&$returnmonitor

}

$returnmonitor = {

&$monitor

}

$check1 = get-content mediate.txt
start-job -scriptblock {$job1}
start-job -scriptblock {$job3}
&$monitor

So far, of the three subroutines in this script, only the $monitor is responding to changes in the text file.  What am I doing wrong with these start-job commands?

• Edited by Chalk-X CPG Wednesday, February 18, 2015 1:24 PM

The script that we're talking about doesn't do anything useful.  It's a simple example that illustrates what I'm trying to accomplish. I thought it would be easier for everyone to follow than the actual script that I'm working on. I'm not expecting these jobs to echo information back to my local session.  As the script indicates I'm expecting them to write information into a text file, from which I can access it with a GUI.  I'm attempting to start two jobs that are perpetual, meaning that the do-loops in these jobs re-launch after each write to the text file. Will the start-job command not run script that's designed to perpetually loop? I need someone to work with me here. 

• Edited by Chalk-X CPG Sunday, February 15, 2015 1:57 AM

I have and will continue to experiment carefully with each new thing I learn.  It frustrates me that I have to wade through so much self-serving banter and personal insults to get one little nugget of real information that I can actually use.  Each time we've had these unpleasant exchanges I've noticed that you don't seem to understand my actual question or the goals I'm describing.  On another thread you eventually caught on and gave me some very useful information and tools that I was able to implement in that project.  If there's anything unclear in my postings, just ask me questions and I'll try to clarify. I'm not trying to build a nuclear aircraft carrier, just a sailboat...so throw me a hammer or a nail. Thanks in advance.

Let me try again to explain my goal and my question.  I need two perpetual loops running concurrently that can read data from and write data to a text file.  I don't need to monitor them or retrieve results from them through powershell, but only via the text file.  I have my reasons for this.  The two concurrently running scripts or jobs will need to pass data back and forth between them via the text file, and a third party GUI will also access the text file. As I stated earlier, I have achieved this with two separate powershell scripts running in two separate windows, but I'm hoping to find a better way.

• Edited by Chalk-X CPG Sunday, February 15, 2015 1:59 AM

I must for this application have TWO loops running because one of them will be sending short spurts of data to a com port during the same time interval that the other loop is playing a media file. I realize it's hard to make sense of this...but this is what's required by the particular external hardware that I'm automating.  Standby for another script example.

• Edited by Chalk-X CPG Wednesday, February 18, 2015 1:32 PM

I haven't had time to study your most recent posting with the "stay in sync" feature.  But after studying the other examples you provided I finally banged out a script that works for my project and "unconventional" hardware.  Please pardon the formatting...I'm not familiar with all the rules yet.  Here's the fruit of our labor:

echo 0 > relay.txt
$read = 0

#######

$relaycontrol = {
cd "c:\m m\cotr"
$port= new-object system.io.ports.serialport com7,4800,none,8,one
$port.open()
'com port is open'

while($true){

while ($read -notmatch 'close port')
{
$read = get-content relay.txt
$read
if ($read -match '0'){'relay is OFF'}
if ($read -notmatch '1'){start-sleep -m 250}
if ($read -notmatch '1'){continue}

'relay is ON'

$port.writeline("1InthebeginningwastheWord,andtheWordwaswithGod,andtheWordwasGod.")

}

$port.close()
'the COM port has been closed'
start-sleep 1

}

}

#######

$soundcontrol = {
cd "c:\m m\cotr"

while($true){

while ($read -notmatch 'close port')
{
'Sounder is waiting'
$read = get-content relay.txt
if ($read -match '0'){start-sleep -m 250}
if ($read -match '0'){continue}

'Received command, requesting relay ON and starting sound'

echo 1 > relay.txt

'$Requested function is'
$read

if ($read -match '1'){$read = 0}
if ($read -match '0'){echo 0 > relay.txt}
if ($read -match '0'){continue}

start-sleep -m 100
.\sounder.exe $read

Wait-Process sounder

echo 0 > relay.txt

}

echo 0 > relay.txt

}

}

#######

$relayjob=start-job -scriptblock $relaycontrol
$soundjob=start-job -scriptblock $soundcontrol

while($true){
$relayjob | get-job | receive-job
$soundjob | get-job | receive-job
start-sleep 1
}

He may not be pretty, but he's my boy.  By the way, jrv, I definitely had to introduce some short sleep cycles to prevent the loops from crashing into each other accessing the text file -- and to trim the resource demands.  Thanks to everyone for the patience and assistance.

• Marked as answer by Chalk-X CPG Wednesday, February 18, 2015 1:19 PM
• Edited by Chalk-X CPG Wednesday, February 18, 2015 5:37 PM

I want to close this thread by attempting to address some comments that were made by one very decorated poster. Obviously we're not all at the same place on the PowerShell learning curve.  When someone turns to this forum, they've probably already sifted through a multitude of web searches unsuccessfully seeking an answer.  Don't assume they are just too lazy to read and dig.  And when someone posts a question on this forum, it shouldn't matter what level they are on.  They should be able to seek answers to their questions without being insulted, ridiculed or belittled. If there's a rule somewhere that says, "You must thoroughly know all the basics of PowerShell scripting before you can access this forum," someone please point it out to me and I will not be heard from again for a while. Otherwise, please spare me and all other padawans the "IT Prolier than thou" attitude. Thanks.

• Edited by Chalk-X CPG Wednesday, February 18, 2015 8:56 PM

I am sorry that you have interpreted things in that way however your init5ial posts and much of you r commentary was argumentative. When you ask for assistance you need to pay attention and try to understand the issues presented. This is fundamental to learning any complex technology. Your insistence on using clearly poor and ambiguous examples made it very hard to sort out your question.  Your refusal to address basic issues made it worse.

If you look at the very first answer given and think about them you will eventually se that the advice was targeted accurately.

Don't take this as negative criticism. It is intended to be constructive criticism. While a "probie" you will be challenged many times. It will take a lot of slaps to the back and front of the head to drive home the lessons.

I don't believe I've been argumentative with anyone except you...and always in response to belittling remarks.  But I do want to "bury the hatchet", because I do appreciate the helpful contributions that you've made to my threads.  I promise I'll try to do a better job presenting my questions if you'll promise to soften your tone...maybe even keep some of your thoughts to yourself.

• Edited by Chalk-X CPG Thursday, February 19, 2015 8:01 PM