Jump to content

Walter Gunter

  • Posts

  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since

Recent Profile Visitors

1,561 profile views

Walter Gunter's Achievements


Newbie (1/14)



  1. Is there a problem, in general, with having a program that is setup as a QMH, that has a subVi that is also a QMH? I ask this question, because I am trying one right now, and I end up with an error that says something like " Wow, that is problem" or something like that. Here is the actual error from the log: <DEBUG_OUTPUT> 11/13/2015 3:27:47.807 PM DAbort 0x8AAA1713: Wow, this is bad e:\builds\penguin\labview\branches\2015\dev\source\execsupp\eventoracle.cpp(538) : DAbort 0x8AAA1713: Wow, this is bad minidump id: f0c3a5cd-99f4-46dc-9a3d-51e7f5b624d9
  2. I have a question about the slave ethernet demon. What timing can be adjusted? Ie, I am having a problem with the connection between my NI Modbus simulator and another controller that is runnning a modbus client interface. I can exchange data, but am having problems with the connection being closed over and over again (from the client side - it doesn't seem to be happy with the response time from the Slave). This causes the Timeout on the slave demon (5 seconds) to kick in and my updates are taking almost 5 seconds. I get the connection to allow for the exchange of data by making the timing of my client(master) have an update rate of 5 seconds. This obviously is not a good thing, and although I am exchanging data, I have to wait a very long time. If i try to lower my client to something reasonable (100 ms is ideal), the client continues to close the connection thinking it is not happy with the response from the slave (ser er). Is there something special I am missing in the TCP layer of the protocol? Should I be setting something else or sending something else from the Labview Modbus TCP once I have a connection?
  3. Had this in another forum and got some additional guidance: https://decibel.ni.com/content/message/64620#64620 Alright, I am a belie-ber in your words, and recognize that I need to implement them (especially, since I went back to the documentation and saw that it specifically called out to make sure I am running my ActorCore code is in parallel with the Call Parent VI). Create a set of user events to manage your front panel updates. Create these events in your Actor Core.vi and bundle them into the actor object prior to invoking the Call Parent node. Then create a loop in your Actor Core.vi that runs in parallel to the Call Parent node which is dynamically registered for the events. When the actor receives a message, the handling function for that message can generate the appropriate event and pass along any relevant data. Alternatively, you may choose to use queues, notifiers, or other mechanisms to communicate with your parallel loop rather than events. Regardless of which mechanism you prefer, National Instruments recommends that you select only one data transfer mechanism within any given actor, and keep the total number of such mechanisms to a minimum within the application as a whole. Be sure to provide a mechanism to stop your parallel loop and trigger that mechanism by overriding Stop Core.vi in your actor child class. How do I provide the mechanism for the loop to stop? I can't just send a STOP string, nor can I use the STOP button at a higher level to send the STOP command to a lower level directly.....Can I? Edit: Okay, I was able to get my actor to stop by making sure the Call Parent Method was parallel to my process, adding an Event, and then sending a message to my QMH queue.
  4. I can see how to launch a core that I override with my own code. I have a state-machine inside my actor core that runs before the Call Parent Method. My problem is how does this framework/queue system allow me to STOP this state machine? I plan to launch four other state machines like this that will all inherit the ACtor Framework. I would like to be able to start and stop them as needed.
  5. awesome timing..I have had to put my program on the back burner as other fires have popped up and had higher priority. I just learned about the Actor Framework at NI Days in DC and determined since I was going down the QMH/State Machine path, that it might be a good idea to use it in my program. So, today, I am starting again and you have posted the LVOOP 2012 examples for my benefit and learning. I will post an update once I make some progress. I might need help determining what my Actors are....
  6. Walter Gunter

    Gunter Awesomes

  7. Sorry about the vague description above. I wrote it while in the middle of the task with me understanding all that I was working on at the time. I sort of figured out where I was having issues, but still not sure why. So, the first time I tried what is shown below, the wire between the class object on the left and the Init.vi in the State Machine was broken. I couldn't figure out why. Then, I just tried it with the init.vi on the outside of the state machine and the wire was no longer broken. While trying to figure out how to explain to you guys my challenge, I again tried to put the Init.vi inside the State Machine, and now i don't have a broken wire. I am losing it...any thoughts. Album: Gunter Awesomes 1 images 0 comments
  8. I am working on some labview code that I really want to use OOP. I have some classes, ie, motor, relay, potentiometer, etc that I am using and wanted to incorporate in a state machine. I wonder if there are some good examples of this? I found a thread on here discussing it http://lavag.org/topic/13064-object-based-state-machine-pattern/ , but I am not clear if it answers my question. 1. When I try to wire a class into a state machine (while loop with a case structure), I always get a broken wire in the while loop. It says the wire type is different? Am I thinking of this incorrectly. I have a class object I put on the block diagram, i wire it to 'Initialize.Vi' and it breaks (there and on any vi from that class). Thanks,
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.