Feel free to make the change and submit a PR.
IIRC those were just for debug output and can be modified or removed
as needed. The primary goal of the hal_pru_generic code is to mimic
as close as possible the hm2 driver behavior, so that's the reference
standard.
On 2/23/2019 3:57 PM, Condit Alan wrote:
> Charles,
>
> As far as I can tell the problem is limited to rtapi_app_main and pru_init.
> In looking at the code, in pru_init, it almost looks like you intended to
> take the rtapi_print calls out after it was working, as they are not indented
> like the rest of the code.
>
> If I were to fix them, I would just find “rtapi_print(" and
> replace with "rtapi_print_msg(RTAPI_MSG_ERR, “ as below (just not preserving
> the commented lines):
>
> // rtapi_print("num_pwmgens : %d\n",num_pwmgens);
> rtapi_print_msg(RTAPI_MSG_ERR, "num_pwmgens : %d\n",num_pwmgens);
> // rtapi_print("num_stepgens: %d\n",num_stepgens);
> rtapi_print_msg(RTAPI_MSG_ERR, "num_stepgens: %d\n",num_stepgens);
> // rtapi_print("num_encoders: %d\n",num_encoders);
> rtapi_print_msg(RTAPI_MSG_ERR, "num_encoders: %d\n",num_encoders);
>
> // rtapi_print("Init pwm\n");
> rtapi_print_msg(RTAPI_MSG_ERR, "Init pwm\n");
>
> If that is acceptable let me know and I will do it and submit a pull request.
>
> Alan
>
>
>
>> On Feb 23, 2019, at 12:07 PM, Charles Steinkuehler
>> <[email protected]> wrote:
>>
>> On 2/23/2019 1:42 PM, mugginsac wrote:
>>> About a month ago Zultron "fixed" a logging problem. He changed rtapi_print
>>> from:
>>>
>>> void rtapi_print(const char *fmt, ...) {
>>> va_list args;
>>> va_start(args, fmt);
>>> rtapi_msg_handler(RTAPI_MSG_ERR, fmt, args);
>>> va_end(args);
>>> }
>>>
>>> to:
>>> void rtapi_print(const char *fmt, ...) {
>>> va_list args;
>>> va_start(args, fmt);
>>> rtapi_msg_handler(RTAPI_MSG_ALL, fmt, args);
>>> va_end(args);
>>> }
>>>
>>> This appears to be what is causing the messages to show up when axis starts
>>> even though there is no error.
>>> However, they show up with an X in a red circle, so it sure looks like an
>>> error. Is there a way to fix the logging problem
>>> without making the user think there is an error???
>>
>> If this is specific to the hal_pru_generic driver, the driver source
>> should probably be fixed. I wrote a fair amount of the driver code
>> before I really understood how the logging worked (esp. since
>> traditional LCNC drivers ran in kernel space).
>>
>> If it's an issue that affects other drivers (esp. the hm2/mesa code),
>> then the "fix" should be reviewed and maybe changed.
>>
>> --
>> Charles Steinkuehler
>> [email protected]
>>
>> --
>> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
>> https://github.com/machinekit
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Machinekit" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/machinekit/TWQy0uCOU2Y/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>
--
Charles Steinkuehler
[email protected]
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
