I stopped using the define_program section in netlinx jobs 10+ years ago.
I can't think of a reason I'd have to use it.
I much prefer to keep the feedback details near the events that cause them to update.
How do you do timed events? Do you check the time in a timeline? define_program was useful for that type of thing although a timeline can do something similar. It had its uses but for most things it isn't necessary. But there are some things where it came in handy so I'd hate to lose it completely. I wish there was a clock event that triggered an event at a certain time/date that you could register, but alas there is none.
Paul
Every job I write creates a timeline like this in define_start:
lTimes[1] = 350 // Update feedback every .35 sec
Timeline_Create(TL_FEEDBACK,lTimes,1,Timeline_Relative,Timeline_Repeat)
It runs forever, and it's going to happen at least twice during any given second, so it's just fine for checking the current time against a trigger value.
Every job I write creates a timeline like this in define_start:
lTimes[1] = 350 // Update feedback every .35 sec
Timeline_Create(TL_FEEDBACK,lTimes,1,Timeline_Relative,Timeline_Repeat)
It runs forever, and it's going to happen at least twice during any given second, so it's just fine for checking the current time against a trigger value.
You could pretty well duplicate what define_program does by making the time 1 ms. In fact it might run more often than define_program. We need Vining to write a test to see which is better, a timeline that runs 1000 times a seconds or define_program.
Paul
Timelines that run quicker than once every 100ms tend to start choking the older netlinx masters, and a timeline of 1ms used to make a very good "kill switch" for your code.
The benefit of using a timeline is that you can tune for performance by making the time period as wide as possible and still making the updates quick enough that the user cannot tell there is any lag. And in practice, I don't actually put anything like button feedback in the TL_FEEDBACK timeline for anything but the simplest of jobs. I usually prefer to handle button feedback in an event-based manner during button pushes, online, and data events.
Anything that actually needs to change 1000 times a second is going to be a problem, and might not be something netlinx can handle.
To put this timescale it in perspective, the time it take a 9600 baud serial port to transmit 10 characters is more than 10ms. So sending a simple command and getting the reply is going to take 20ms+ just in transmission delays, not accounting for the controlled device's processing time. So that's brought the potential event load down to under 50 per second right there. (assuming a device that requires a continuous stream of communication)
Thank you for your tips. Tomorrow I'll code a new version of my COMM/UI modules doing the button feedback in the events and using the timeline for the commands queue and polling status. Let's see how it works.
The only port open between the both side are 1319.
Raphaël Thiffault
I remember sitting at the VIP conference this Summer when they showed us the NX and my mind was spinning on the whole extra LAN on the box. The engineers were obviously a little concerned that we were running off into the weeds on the use of this feature. While it seems like there would be a whole host of things you could do it is really basically a convenience meant to add some flexibility and ease by offering a simple separate network for your NXB boxes and TPs where you don't need remote access. You can still uplad/download TP files via the NX master which is connected via the normal LAN.
I really think it's a feature aimed at the lower level system designers since you can easily hook up all the NXB boxes and UIs without needing to manage a network.
I have done a couple installs now with the NX masters and I have noticed a pretty marked improvement overall. They are clearly very fast. I also notice Duet modules aren't nearly as boggy on bootup. Overall, I'm very happy with them so far. I'm benching one here at my office and beating it up pretty badly. It's taking it and performing quite well. +1 on the screw-in phoenix power connector.
If connect the icslan port to a switch and your TPs and PCs to the same switch I would think vnc would work like normal.
Now if you connect your icslan port and ethernet port to a layer 3 switch you could probably route between the two but at that point why even use the icslan, just create your vlans and svi's to manage, isolate and route as neededs using acl's.
Anyone else notice that the Duet module command echo is now registering a DATA_EVENT at the Netlinx layer? Use to be on an NI that the echo was only observed through Notifications. Turning into a bit of a PITA.
Comments
How do you do timed events? Do you check the time in a timeline? define_program was useful for that type of thing although a timeline can do something similar. It had its uses but for most things it isn't necessary. But there are some things where it came in handy so I'd hate to lose it completely. I wish there was a clock event that triggered an event at a certain time/date that you could register, but alas there is none.
Paul
It runs forever, and it's going to happen at least twice during any given second, so it's just fine for checking the current time against a trigger value.
You could pretty well duplicate what define_program does by making the time 1 ms. In fact it might run more often than define_program. We need Vining to write a test to see which is better, a timeline that runs 1000 times a seconds or define_program.
Paul
The benefit of using a timeline is that you can tune for performance by making the time period as wide as possible and still making the updates quick enough that the user cannot tell there is any lag. And in practice, I don't actually put anything like button feedback in the TL_FEEDBACK timeline for anything but the simplest of jobs. I usually prefer to handle button feedback in an event-based manner during button pushes, online, and data events.
Anything that actually needs to change 1000 times a second is going to be a problem, and might not be something netlinx can handle.
To put this timescale it in perspective, the time it take a 9600 baud serial port to transmit 10 characters is more than 10ms. So sending a simple command and getting the reply is going to take 20ms+ just in transmission delays, not accounting for the controlled device's processing time. So that's brought the potential event load down to under 50 per second right there. (assuming a device that requires a continuous stream of communication)
Is is possible to VNC into a touchpanel on the ICSLan from the Lan port? If so, how is this done?
TIA,
jrw
Raphaël Thiffault
I remember sitting at the VIP conference this Summer when they showed us the NX and my mind was spinning on the whole extra LAN on the box. The engineers were obviously a little concerned that we were running off into the weeds on the use of this feature. While it seems like there would be a whole host of things you could do it is really basically a convenience meant to add some flexibility and ease by offering a simple separate network for your NXB boxes and TPs where you don't need remote access. You can still uplad/download TP files via the NX master which is connected via the normal LAN.
I really think it's a feature aimed at the lower level system designers since you can easily hook up all the NXB boxes and UIs without needing to manage a network.
Now if you connect your icslan port and ethernet port to a layer 3 switch you could probably route between the two but at that point why even use the icslan, just create your vlans and svi's to manage, isolate and route as neededs using acl's.