Serial communications through USB, problems receiving

[RavensFan]

The only other case I can think of is if you want a terminal application where you want to display whatever bytes there are as soon as they arrive, but you don't care about their grouping or need to parse them out into pieces of useful data.

[Hobbs23]

This is is how I implemented what I thought you were saying. It does seem to work. I like constructive criticism, so if you have a tweak please let me know.

Thanks again everyone!

[RavensFan]

I've never used the ASRL End Out property node.  I prefer to explicitly place the termination character into any command that I write out.

I don't understand the first while loop after the CONF write command.  It looks like you are just creating a delay loop where the number of iterations is (0, 1, 2, 4, 7, 11, 16, 22, 29, 37, 46, 56)  12 times 10 msec. or 120 milliseconds.  Why?  That is a Rube Goldberg when you could just have a 120 msec delay.  And you don't even need that because the VISA Read will wait until it gets either 50 bytes or the termination character.

[arteitle]

I have a few (rhetorical) questions about how you've implement this. First, What's the reason for inserting a 520 ms delay between the VISA Write and the VISA Read, and why are you doing it in such a roundabout way? You've set up the while loop in a very confusing way to always execute 52 times, basically turning it into a for loop, and instead of just using a 520 ms delay, you're using a 10 ms delay but calling it 52 times in a row. The VISA Read is going to wait until bytes come in anyway, so why add an extra delay before it?

Second, are you actually expecting to receive 10 responses to your one transmission of "CONF"? You've put your VISA Read in a for loop that repeats 10 times, so it's going to try to receive 10 separate replies in a row. Also, what are you trying to accomplish by testing if the for loop's iteration number is greater than 9 and wiring that to the Stop terminal? By wiring 10 to the count terminal you've ensured that the loop will run (at most) 10 times, so when it completes the tenth run the iteration number will be 9, not greater than 9.

I think you need to study more on how while and for loops work.

[Intaris]

You have the number of iterations wrong.  (i-1)+1 is 1,2,3,4,5,6,7,8,......50,51. It's equivalent to just wiring the i terminal to the ">50" part except for the fact that this code will wait only on every second iteration as the shift register is uninitialised.

Either way, it's a whack way of timing.

[jwscs]

@ravensfan you are right that this is a tiny rube goldberg, but i don't think it really is arithmetic series, bc it only incrments the current "i" and pushes it into the shift register,

so the shift register holds "i+1" at the end of each iteration.

edit: yeah im too slow 😉

[Hobbs23]

I like the feedback... If I can apply it properly... it is even better!  Ok, RavensFan, I will pull the delay because I missed the upgrade implications. As far as the Delay being done correctly regardless of just adding a 120msec delay. Is this the change that everyone was alluding to? Your other suggestions I will fiddle with and try to get them to work for me. Thanks

[arteitle]

Yes, that's a very, very strange way to create a fixed delay. (I posted a longer reply earlier today but it seems to have vanished, maybe it'll reappear eventually.) Anyway, what you have there is a 520 ms wait created by performing a 10 ms wait 52 times. Here's why that's weird: First, if you want a delay of a certain length, it's much simpler to just wire the length you want into the wait function without doing any looping. Second, if you want a loop that executes a fixed number of times, just use a for loop. Third, if you really want to use a while loop instead, normally you'd just compare the iteration terminal to a fixed constant and wire the result of that compare to the stop terminal. Instead you're incrementing the iteration number, then passing it to the next iteration through a shift register, then comparing it, which is just needlessly complex. I see here you moved the increment which makes no difference. There's no reason for the increment, or the shift register, or the while loop instead of a for loop, or even a loop at all.

[RavensFan]

---

@jwscs wrote:

@RavensFan you are right that this is a tiny rube goldberg, but i don't think it really is arithmetic series, bc it only incrments the current "i" and pushes it into the shift register,

so the shift register holds "i+1" at the end of each iteration.

edit: yeah im too slow 😉

---

You and intaris are right.  I think when I looked at this I was thinking the shift register was wiring in the addition. and thus growing by increasing amounts each iteration.  The tight packing of everything in that tiny loop through me off.

[Hobbs23]

I'm able to communicate now with your help, and I do get all of the info that the unit is sending. Thank you. The way I am implementing the solution may be still in error because I get a receive timeout error of 1073807339, which goes away when I put bytes to read at 1. What do you think?