Details of the latest release of the BACRabbit BACnet stack are available at
https://sourceforge.net/news/?group_id09224&id)4268.
Regards,
Peter Mc Shane
Release 011 of the BACRabbit BACnet stack
Started by ●November 22, 2010
Reply by ●November 23, 20102010-11-23
Hi Peter,
Do you have any sample code that shows how to use Send_UEvent_Notify() ? Have you tested that function? I'm trying to broadcast a change of state for a binary value.
I'm a bit sketchy as to what all the fields of the BACNET_EVENT_NOTIFICATION_DATA argument should be, particularly processIndentifier, and it seems to crash the whole server application hard when I guess.
My basic BACnet task on my RCM5760 application is working. I got an RCM5600W to use as client test device, and they are successfully exchanging "I am" "who is" messages.
--- In r..., "petermcs" wrote:
>
> Details of the latest release of the BACRabbit BACnet stack are available at https://sourceforge.net/news/?group_id09224&id)4268.
>
> Regards,
> Peter Mc Shane
>
Do you have any sample code that shows how to use Send_UEvent_Notify() ? Have you tested that function? I'm trying to broadcast a change of state for a binary value.
I'm a bit sketchy as to what all the fields of the BACNET_EVENT_NOTIFICATION_DATA argument should be, particularly processIndentifier, and it seems to crash the whole server application hard when I guess.
My basic BACnet task on my RCM5760 application is working. I got an RCM5600W to use as client test device, and they are successfully exchanging "I am" "who is" messages.
--- In r..., "petermcs" wrote:
>
> Details of the latest release of the BACRabbit BACnet stack are available at https://sourceforge.net/news/?group_id09224&id)4268.
>
> Regards,
> Peter Mc Shane
>
Reply by ●November 23, 20102010-11-23
The crashing part was due to stack underflow, which I fixed, but I could still
use a sample if you have one, thanks in advance if you do...
--- In r..., "exrabbit2" wrote:
>
> Hi Peter,
>
> Do you have any sample code that shows how to use Send_UEvent_Notify() ? Have you tested that function? I'm trying to broadcast a change of state for a binary value.
>
> I'm a bit sketchy as to what all the fields of the BACNET_EVENT_NOTIFICATION_DATA argument should be, particularly processIndentifier, and it seems to crash the whole server application hard when I guess.
>
> My basic BACnet task on my RCM5760 application is working. I got an RCM5600W to use as client test device, and they are successfully exchanging "I am" "who is" messages.
>
> --- In r..., "petermcs" wrote:
> >
> > Details of the latest release of the BACRabbit BACnet stack are available at https://sourceforge.net/news/?group_id09224&id)4268.
> >
> > Regards,
> > Peter Mc Shane
>
--- In r..., "exrabbit2" wrote:
>
> Hi Peter,
>
> Do you have any sample code that shows how to use Send_UEvent_Notify() ? Have you tested that function? I'm trying to broadcast a change of state for a binary value.
>
> I'm a bit sketchy as to what all the fields of the BACNET_EVENT_NOTIFICATION_DATA argument should be, particularly processIndentifier, and it seems to crash the whole server application hard when I guess.
>
> My basic BACnet task on my RCM5760 application is working. I got an RCM5600W to use as client test device, and they are successfully exchanging "I am" "who is" messages.
>
> --- In r..., "petermcs" wrote:
> >
> > Details of the latest release of the BACRabbit BACnet stack are available at https://sourceforge.net/news/?group_id09224&id)4268.
> >
> > Regards,
> > Peter Mc Shane
>
Reply by ●November 24, 20102010-11-24
Hi,
I haven't played around with the event code myself yet so can't speak directly from experience but...
There is some example code available on this in the C version of the stack. There is an app for sending UCOV messages in the demo\ucov directory.
When you get to the stage where you are tackling COV notification it is probably a good idea to have a copy of the standard as that will give you the details on all the messages and their parameters. At 881 pages plus addendums it is not exactly light reading!
According to the standard the process ID is "This parameter, of type Unsigned32, shall convey a numeric "handle" meaningful to the subscriber. This handle shall be used to identify the process within the COVclient that should receive the notification. The value of zero is reserved for unsubscribed COV."
Hope this sheds a little bit of light on the issue.
Regards,
Peter
--- In r..., "exrabbit2" wrote:
>
> The crashing part was due to stack underflow, which I fixed, but I could still use a sample if you have one, thanks in advance if you do...
>
I haven't played around with the event code myself yet so can't speak directly from experience but...
There is some example code available on this in the C version of the stack. There is an app for sending UCOV messages in the demo\ucov directory.
When you get to the stage where you are tackling COV notification it is probably a good idea to have a copy of the standard as that will give you the details on all the messages and their parameters. At 881 pages plus addendums it is not exactly light reading!
According to the standard the process ID is "This parameter, of type Unsigned32, shall convey a numeric "handle" meaningful to the subscriber. This handle shall be used to identify the process within the COVclient that should receive the notification. The value of zero is reserved for unsubscribed COV."
Hope this sheds a little bit of light on the issue.
Regards,
Peter
--- In r..., "exrabbit2" wrote:
>
> The crashing part was due to stack underflow, which I fixed, but I could still use a sample if you have one, thanks in advance if you do...
>
Reply by ●November 24, 20102010-11-24
Hi Peter,
I'll probably spring for the standard.
It seems like Send_UEvent_Notify() isn't fully implemented on the receiving end because the function to decode that message isn't called from any handler that I can see. Send_UCOV_Notify() will probably serve my purposes well enough. I got that one working but I had to change a far pointer in two stack structs to near to get it to work, and I'm not sure why yet. There is also some printf() code used when PRINT_ENABLED is on that's missing far and long specifiers so it was putting out garbage characters.
--- In r..., "petermcs" wrote:
>
> Hi,
>
> I haven't played around with the event code myself yet so can't speak directly from experience but...
>
> There is some example code available on this in the C version of the stack. There is an app for sending UCOV messages in the demo\ucov directory.
>
> When you get to the stage where you are tackling COV notification it is probably a good idea to have a copy of the standard as that will give you the details on all the messages and their parameters. At 881 pages plus addendums it is not exactly light reading!
>
> According to the standard the process ID is "This parameter, of type Unsigned32, shall convey a numeric "handle" meaningful to the subscriber. This handle shall be used to identify the process within the COVclient that should receive the notification. The value of zero is reserved for unsubscribed COV."
>
> Hope this sheds a little bit of light on the issue.
>
> Regards,
> Peter
>
> --- In r..., "exrabbit2" wrote:
> >
> > The crashing part was due to stack underflow, which I fixed, but I could still use a sample if you have one, thanks in advance if you do...
>
I'll probably spring for the standard.
It seems like Send_UEvent_Notify() isn't fully implemented on the receiving end because the function to decode that message isn't called from any handler that I can see. Send_UCOV_Notify() will probably serve my purposes well enough. I got that one working but I had to change a far pointer in two stack structs to near to get it to work, and I'm not sure why yet. There is also some printf() code used when PRINT_ENABLED is on that's missing far and long specifiers so it was putting out garbage characters.
--- In r..., "petermcs" wrote:
>
> Hi,
>
> I haven't played around with the event code myself yet so can't speak directly from experience but...
>
> There is some example code available on this in the C version of the stack. There is an app for sending UCOV messages in the demo\ucov directory.
>
> When you get to the stage where you are tackling COV notification it is probably a good idea to have a copy of the standard as that will give you the details on all the messages and their parameters. At 881 pages plus addendums it is not exactly light reading!
>
> According to the standard the process ID is "This parameter, of type Unsigned32, shall convey a numeric "handle" meaningful to the subscriber. This handle shall be used to identify the process within the COVclient that should receive the notification. The value of zero is reserved for unsubscribed COV."
>
> Hope this sheds a little bit of light on the issue.
>
> Regards,
> Peter
>
> --- In r..., "exrabbit2" wrote:
> >
> > The crashing part was due to stack underflow, which I fixed, but I could still use a sample if you have one, thanks in advance if you do...
>
Reply by ●November 24, 20102010-11-24
Hi,
You will need to instaall the handler on the receiving end using something like:
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_COV_NOTIFICATION, handler_cov_notification);
Which should pull in the demo handler for this. The demo handler just prints the details out so you would need to add in the application specific handling you need to do when you get your notification.
Send me the details of the changes you made to get things to work and I'll update the stack.
Regards,
Peter
--- In r..., "exrabbit2" wrote:
>
> Hi Peter,
> I'll probably spring for the standard.
>
> It seems like Send_UEvent_Notify() isn't fully implemented on the receiving end because the function to decode that message isn't called from any handler that I can see. Send_UCOV_Notify() will probably serve my purposes well enough. I got that one working but I had to change a far pointer in two stack structs to near to get it to work, and I'm not sure why yet. There is also some printf() code used when PRINT_ENABLED is on that's missing far and long specifiers so it was putting out garbage characters.
>
> --- In r..., "petermcs" wrote:
> >
> > Hi,
> >
> > I haven't played around with the event code myself yet so can't speak directly from experience but...
> >
> > There is some example code available on this in the C version of the stack. There is an app for sending UCOV messages in the demo\ucov directory.
> >
> > When you get to the stage where you are tackling COV notification it is probably a good idea to have a copy of the standard as that will give you the details on all the messages and their parameters. At 881 pages plus addendums it is not exactly light reading!
> >
> > According to the standard the process ID is "This parameter, of type Unsigned32, shall convey a numeric "handle" meaningful to the subscriber. This handle shall be used to identify the process within the COVclient that should receive the notification. The value of zero is reserved for unsubscribed COV."
> >
> > Hope this sheds a little bit of light on the issue.
> >
> > Regards,
> > Peter
> >
> > --- In r..., "exrabbit2" wrote:
> > >
> > > The crashing part was due to stack underflow, which I fixed, but I could still use a sample if you have one, thanks in advance if you do...
> > >
>
You will need to instaall the handler on the receiving end using something like:
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_COV_NOTIFICATION, handler_cov_notification);
Which should pull in the demo handler for this. The demo handler just prints the details out so you would need to add in the application specific handling you need to do when you get your notification.
Send me the details of the changes you made to get things to work and I'll update the stack.
Regards,
Peter
--- In r..., "exrabbit2" wrote:
>
> Hi Peter,
> I'll probably spring for the standard.
>
> It seems like Send_UEvent_Notify() isn't fully implemented on the receiving end because the function to decode that message isn't called from any handler that I can see. Send_UCOV_Notify() will probably serve my purposes well enough. I got that one working but I had to change a far pointer in two stack structs to near to get it to work, and I'm not sure why yet. There is also some printf() code used when PRINT_ENABLED is on that's missing far and long specifiers so it was putting out garbage characters.
>
> --- In r..., "petermcs" wrote:
> >
> > Hi,
> >
> > I haven't played around with the event code myself yet so can't speak directly from experience but...
> >
> > There is some example code available on this in the C version of the stack. There is an app for sending UCOV messages in the demo\ucov directory.
> >
> > When you get to the stage where you are tackling COV notification it is probably a good idea to have a copy of the standard as that will give you the details on all the messages and their parameters. At 881 pages plus addendums it is not exactly light reading!
> >
> > According to the standard the process ID is "This parameter, of type Unsigned32, shall convey a numeric "handle" meaningful to the subscriber. This handle shall be used to identify the process within the COVclient that should receive the notification. The value of zero is reserved for unsubscribed COV."
> >
> > Hope this sheds a little bit of light on the issue.
> >
> > Regards,
> > Peter
> >
> > --- In r..., "exrabbit2" wrote:
> > >
> > > The crashing part was due to stack underflow, which I fixed, but I could still use a sample if you have one, thanks in advance if you do...
> > >
>
Reply by ●November 30, 20102010-11-30
Hi again Peter,
I want to enable summary alarm support for a binary value object. My comparison of the spec and the stack code led me to conclude that the ability to write the properties needed to do this isn't implemented yet, and I'm going to have to code it if I want it. Does this sound correct?
Thanks again,
Brian.
I want to enable summary alarm support for a binary value object. My comparison of the spec and the stack code led me to conclude that the ability to write the properties needed to do this isn't implemented yet, and I'm going to have to code it if I want it. Does this sound correct?
Thanks again,
Brian.
Reply by ●November 30, 20102010-11-30
Hi Brian,
I'm afraid that is indeed the case. I do plan to increase the utility of the example objects as time goes by but it will be a case of implementing those features I need myself for the most part as maintaining the stack is a significant amount of work.
Let me know how you get on and don't hesitate to ask if you have further questions :)
Regards,
Peter
--- In r..., "exrabbit2" wrote:
>
> Hi again Peter,
>
> I want to enable summary alarm support for a binary value object. My comparison of the spec and the stack code led me to conclude that the ability to write the properties needed to do this isn't implemented yet, and I'm going to have to code it if I want it. Does this sound correct?
>
> Thanks again,
> Brian.
>
I'm afraid that is indeed the case. I do plan to increase the utility of the example objects as time goes by but it will be a case of implementing those features I need myself for the most part as maintaining the stack is a significant amount of work.
Let me know how you get on and don't hesitate to ask if you have further questions :)
Regards,
Peter
--- In r..., "exrabbit2" wrote:
>
> Hi again Peter,
>
> I want to enable summary alarm support for a binary value object. My comparison of the spec and the stack code led me to conclude that the ability to write the properties needed to do this isn't implemented yet, and I'm going to have to code it if I want it. Does this sound correct?
>
> Thanks again,
> Brian.
>
