make sequence on case+for structure

[zaqap]

Hello,I made a code that will send CAN frames one after second in define order. I did this as an enclosed picture, however this structure does not always work.  What can be the cause, does this form is incorrect?  Message Edited by zaqap on 08-13-2008 05:24 AM


PROGRAMOS.JPG:
Loading Image...

[MikeS81]

Hi zaqap,what doesn´t always work? What do you make in the other cases? The second subvi icon tells me that it has to do with a wait function, why do you use another wait in the loop?Mike

[zaqap]

Hi Mike,in the other cases there is a following frames and the problem consist in that sometimes program sending all frames and sometimes only one(first). The wait function wait for next state to occur an object Zaqap 

[MikeS81]

Hi Zaqap,did you check if you have an error in your error cluster? I guess if you have an error, then you don´t send your data.Mike

[zaqap]

I check it, no errors..

[muks]

Hi zaqab,               Can you post your code? 

[zaqap]

Hi,sequence stucture doesn't work with this,  metronome give CPU time to handle other task. In attachment I post sample code


sample code.vi:
http://forums.ni.com/ni/attachments/ni/170/349027/1/sample code.vi

[smercurio_fc]

Why are you using a for-loop for that? Just place the Write-Wait pairs in sequence. The metronome wait seems to serve no purpose. Message Edited by smercurio_fc on 08-13-2008 09:07 AM

[smercurio_fc]

Offhand I see no procedural issue. In the first iteration of the loop an 8-byte array is sent. In the second a 5-byte array. I'm suspecting the problem is really with your instrument. Are you sure you are waiting enough time after sending the 8-byte array before sending the 5-byte array? Perhaps the instrument is still busy moving.  Side notes:- Normally when using an event structure one places the buttons inside the event case. This way they're not free-floating, and they will be read and reset by the event structure.
- The mechanical action for "Stop Motor" is different than the other buttons. Is this intentional?
- Not having the up/down controls visible for the numeric control makes it look like an indicator, so that may confuse some people.
- You really need to clean up your wiring.
-  Passing out the "ObjDataOut" from each event case is pointless since you're not using a shift register, so the value read at the beginning of the loop at the loop tunnel is the one that will always be used. Either use a shift register or don't pass it out. 

[altenbach]

smercurio_fc wrote:
Side notes:...
One more note: - It seems all your event cases differ only by the value of the array. Most likely, you could consolidate all the duplicate code so the event frames only contain the array. The second call in the case of current interest could be handled in the timeout case, for example or some other state machine code.
 Can you rewrite the code to replace all the instrument IO with a simple indicator so we can run it without needing your hardware?

[zaqap]

I apologize guys but I cut out this fragment of code on quickly returning my attention only the place where problem begins, but thans for criticism
smercurio_fc wrote:
In the first iteration of the loop an 8-byte array is sent. In the second a 5-byte array. Are you sure you are waiting enough time after sending the 8-byte array before sending the 5-byte array? Perhaps the instrument is still busy moving.  
  My mistake! i don't nottice this, there should be zeros in the last 3 bit in second frame. Both should have be an 8-byte, but i dont have hardware now to check if this solve problem 
smercurio_fc wrote:
- The mechanical action for "Stop Motor" is different than the other buttons. Is this intentional?
no i only verify difference in working  
smercurio_fc wrote:

Side notes:- Normally when using an event structure one places the buttons inside the event case. This way they're not free-floating, and they will be read and reset by the event structure.
  I learnig LabView since month, I saw this kind of method in one of NI example, thougth it's good 

-  Passing out the "ObjDataOut" from each event case is pointless since you're not using a shift register, so the value read at the beginning of the loop at the loop tunnel is the one that will always be used. Either use a shift register or don't pass it out. 

I correct it 
altenbach wrote:   - It seems all your event cases differ only by the value of the array. Most likely, you could consolidate all the duplicate code
so the event frames only contain the array. The second call in the case
of current interest could be handled in the timeout case, for example
or some other state machine code.
 I konw about that but I don't konw exactly how to do this, and about the rewrite code it hard to replace IO to code still have sense