Graphing Digital Outputs


cadcoke5

Recommended Posts

I want a square-wave type of 2D Graph for my digital output. This output is controlled by a toggle switch on the same screen.  I can create the graph, but the graph does not continuously scroll.  Rather, it is normaly stopped, but when ever the switch is toggled, the graph will jump to the current time. Also, the graph itself is not a square wave, but rather it draws a sloped line from the last point.  The result is a saw-tooth type of wave form, which is not appropriate

 

is there a way to create a square-wave type of graph for a digital output that continuously scrolls?

 

I have attached a screen grab for the graph and the properties.

 

-Joe

post-9190-0-63162900-1392137342_thumb.pn

post-9190-0-94439400-1392137353_thumb.pn

Link to comment
Share on other sites

Yes, create a test Dig Out channel.  Call it, say, contPowerSwitch.  Then create a sequence that looks like this:

 

while(1)

   if (!isEmpty(powerSwitch[0]))

      contPowerSwitch = powerSwitch[0]

   endif

   delay(0.1)

endwhile

 

You can drop the if() if you make sure not to start the sequence until after you've initialized your powerswitch output channel.

Link to comment
Share on other sites

I did figure out how to get the graph to show a square wave.  You must first go to the graph properties, on the Axis tab, and then choose "Step" as the "plotting method". But, that initially only showed vertical lines, and not the horizontal part of the square wave. What was happening, was that I had set the vertical axis to range from 0 to 1, but that causes any horizontal lines to be invisible. Perhaps the perimeter of the graph covers them up.  So, by extending the range a bit, i.e. from -0.1 to + 1.1, I was able to get the horizontal elements to show up.

 

I did one more experiement because of the timing and scroll issue.  I added the digital graph to my existing analog input graph. But, even then, the trace does not keep up with the analog trace.  Rather the trace of the digital output stops until you toggle the output.

 

I see that I must program a sequence to solve this graphing problem.  But, I will have to learn more about sequences before I can implement that idea.

 

Thank you for the help,

-Joe

Link to comment
Share on other sites

The problem is that digital output channels (and analog ones) only get new values when they change state.  That's why you need the sequence.  You need to create a channel that has values all the time that show the current state at those time intervals.  Another way to do it is in the Event of one of your input channels.  There you can just do:

 

contPowerSwitch = powerSwitch[0]

 

Then you don't need the sequence, though you will still need to create a Test D to A channel called contPowerSwitch.

Link to comment
Share on other sites

  • 2 months later...

I know your tech support worked with me via desktop sharing to create a solution, but there was a fatal error that caused it to be lost.  Also, it was definitely going over my head, and I did not follow much of it.  But, now I am ready to jump back into this aspect of the program.  In particular, because I am ready to add the code to log my activity to the disk.  I must log both the readings coming in via. the analog inputs to LabJack  and the digital outputs as we control the process. I know a limitation of the program is that you cannot just log a digital output, so I must manage it some other way.

 

The creation of a dummy channel seems to be a good way to both display when the outputs are on, in a graph, and to enable logging of that data.  Is this what DAQFactory calls a "Virtual Channel"?

 

-Joe

Link to comment
Share on other sites

No, virtual channels are a left over from when DAQFactory didn't have a powerful scripting language.  They were a way of doing variables.  Alas, people still seem to like to use them for other things, probably because you can easily see their contents, so we have kept them around.  By a dummy channel I mean a test channel with TIming = 0 that you do addValue() on: myChannel.addValue(someValue)

Link to comment
Share on other sites

Yes they are identical, except if you use addValue(), conversions don't apply.  You can get around this by creating a test D to A channel and using this format:

 

myChannel = newValue

 

however, this is slightly slower, which doesn't matter that often.

Link to comment
Share on other sites

The manual is not clear about the issue of virtual channels, vs. test channels.  I didn't come across anything in the manual suggesting that virtual channels are not as desirable as test channels.  Though, the words "channel" and "Test" occur quite often in the manual, so it is certainly possible I overlooked the page discussing this.

 

You indicate that virtual channels are "left over", hinting that test channels are more desirable. Though, the name suggests that it is just for testing, so perhaps that is putting me off.  Perhaps in the manual you can rename them to be something like, "test/storage channels" to make it clear that this is the preferred way to store values not coming from an input channel, if that is the case.

 

So, why is a test channel preferred over a virtual channel?

 

-Joe

Link to comment
Share on other sites

I have created the Test Channel, and am working to add code to make it work.  However, there is a screen component that has me stumped.

 

I have a toggle switch to manually turn on/off my heater via a digital output.  I know I can toggle an output channel, and had actually added the toggle switch to a small panel, so that I can simply press anywhere on the panel and the switch and output will toggle.  I found that I can also add an additional action to the panel, which will add the current status of the switch to the Temp channel, so it can be logged.

 

However, I can't figure out how to make the toggle switch itself cause the Temp channel to log my action.

 

-Joe

Link to comment
Share on other sites

Test channels were created to test with, thus the name.  They are used in the guided tour to allow people that don't have hardware to try DAQFactory.  Thus the name.  However, I have found them to be useful for other things, and thus mention them a lot in the forum.  This is because they act just like real channels. Its like a lot of things.  A screwdriver was named because it was designed to drive screws, however, it also is sometimes useful as a paint can opener, but I don't think the name needs to be changed to reflect that.

 

As for virtual channels, those are the ones that probably could use a different name since in some ways (such as logging) they don't act like channels.  We're open to suggestions.

 

As for logging an output, you have a toggle switch on the screen that controls the actual digital output channel.  You can log that channel directly, but since it only gets a new value when it changes, you'll only get the value logged at those instants.  If you want a continuous log of the state, you have 3 choices:

 

1) use snapshot mode for logging

2) do a readback of the output by creating a second channel.  The hardware you have may support reading the digital state, or you can always just run a wire to one of your inputs and read that channel.  This is the best method.

3) create a test channel as we've discussed, and a sequence that goes out every so often and copies the last reading from the digital out channel to the test channel.  You can also do this in the event of one of your input channels.  

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.